2011年2月25日金曜日
Response Timeを超えるFirst Byte Timeが表示される理由
まずこの画像をご覧下さい。この画像はサムライズのトップページをCompuware GomezのSynthetic Monitoring - Backboneで計測したデータをコンポーネントチャートとして表示したものです。赤丸で囲んだデータと青丸で囲んだデータに注目して下さい。これは1st Byte TimeがResponse Timeを超えた状況を示しています。1st Byte TimeはクライアントがページオブジェクトをWebサーバーにリクエストしてから最初のパケットを受け取るまでの時間を示しています。一方、Response Timeはページオブジェクトの最後のパケットを受け取るまでの時間を示しています。普通に考えたら、1st Byte TimeがResponse Timeを超えるのはおかしいはずです。何故このような現象になるかについて、この記事で纏めます。
上の画像をご覧下さい。これはコンポーネントチャートの1st Byte TimeがResponse Timeを超えている時間の計測データのウォーターフォールチャートです。紫色が1st Byte Timeを示しています。そして、ウォーターフォールチャートの一番上、青色がResponse Timeを示しています。もう既に気がつかれた方が居られるかも知れませんが、紫色の棒グラフを全部繋げて一直線に並べてみて下さい。どうでしょう?青色の棒グラフより長くなりませんか?
これが答えです。コンポーネントチャートでは全てのオブジェクトの1st Byte Timeを足した数値を示しています。しかし、実際のブラウザは並列処理でオブジェクトをリクエストするので、例えば、3個のオブジェクトがそれぞれ2秒ずつ1st Byte Timeに掛かったとしても、実際には2秒で全て処理されます。2×3で6秒と言う事はありません。種明かしをするとなんてこと無いのですが、良くある質問ですので記事として纏めました。
2011年2月24日木曜日
第1回通販業界Webサイトパフォーマンスランキング掲載のお知らせ
本日(2011年2月24日)サムライズはGomez Performance Network(GPN)を使い、通販新聞社が2010年12月に実施した「第55回通販・通教売上高ランキング調査」の上位30社の主要サイトトップページを測定した結果をランキングとして発表しました。詳細については下記をご覧下さい。
サムライズFacebookサイトランキングページ
プレスリリース
通販サイトランキングTOP5
サムライズFacebookサイトランキングページ
プレスリリース
通販サイトランキングTOP5
2011年2月22日火曜日
Active Backboneにおける特定オブジェクトのトラッキング方法
Backboneテストのウォーターフォールチャートを見ていて、あるオブジェクトの処理に時間が掛かっているのを見つけたと仮定します。ウォーターフォールチャートはある一つのテストについての結果ですから、他のテストでそのオブジェクトがどうであったかを調べるには、いちいちアベレージチャートに戻って他のテストを選択しなければなりません。ちょっと面倒ですね。こんな時、この記事でご紹介する方法を使うと便利です。
■平均応答時間
では、サンプルを例に進めていきます。下図のように通常は10秒前後の応答時間で比較的高い頻度で30秒以上のスパイクがあるサイトがあります。
■コンポーネントチャート
コンポーネントチャートを表示してみると、コンテンツダウンロードに時間が掛かっている事が分かります。
■ウォーターフォールチャート
大きなスパイクを示すテストを選択してウォーターフォールチャートを確認します。すると飛び抜けてコンテンツダウンロードに時間が掛かっているオブジェクトがあります。このオブジェクトと、比較対象となるオブジェクトを幾つか選んでファイル名をメモしておきます。
■オブジェクトトラッキング
下図の手順で先程メモしたオブジェクトを選択し一定の計測期間でどうであったかを確認してみましょう。
■オブジェクトの選択
■特定オブジェクトの平均応答時間
ウォーターフォールチャートで飛び抜けてコンテンツダウンロードに時間の掛かっていたオブジェクトが平均応答時間のチャートとほぼ同様の折れ線グラフの形状を示している事が分かります。やはり,このオブジェクトが原因で全体の応答時間を押し上げている事が明確になりました。
■特定オブジェクトのコンポーネントチャート
上図のチャートをコンポーネントチャートとして表示しています。やはり問題のオブジェクトのコンテンツダウンロードに多くの時間を消費している事が分かります。(黄色の棒グラフ)
■ヒント
CDNサービスを利用している場合、この方法は便利でしょう。CDNに置いているオブジェクトをトラッキングする事で効果を見る事が出来るはずです。
■平均応答時間
では、サンプルを例に進めていきます。下図のように通常は10秒前後の応答時間で比較的高い頻度で30秒以上のスパイクがあるサイトがあります。
■コンポーネントチャート
コンポーネントチャートを表示してみると、コンテンツダウンロードに時間が掛かっている事が分かります。
■ウォーターフォールチャート
大きなスパイクを示すテストを選択してウォーターフォールチャートを確認します。すると飛び抜けてコンテンツダウンロードに時間が掛かっているオブジェクトがあります。このオブジェクトと、比較対象となるオブジェクトを幾つか選んでファイル名をメモしておきます。
■オブジェクトトラッキング
下図の手順で先程メモしたオブジェクトを選択し一定の計測期間でどうであったかを確認してみましょう。
■オブジェクトの選択
■特定オブジェクトの平均応答時間
ウォーターフォールチャートで飛び抜けてコンテンツダウンロードに時間の掛かっていたオブジェクトが平均応答時間のチャートとほぼ同様の折れ線グラフの形状を示している事が分かります。やはり,このオブジェクトが原因で全体の応答時間を押し上げている事が明確になりました。
■特定オブジェクトのコンポーネントチャート
上図のチャートをコンポーネントチャートとして表示しています。やはり問題のオブジェクトのコンテンツダウンロードに多くの時間を消費している事が分かります。(黄色の棒グラフ)
■ヒント
CDNサービスを利用している場合、この方法は便利でしょう。CDNに置いているオブジェクトをトラッキングする事で効果を見る事が出来るはずです。
2011年2月21日月曜日
Active Backboneにおける均一性の求め方
GPNのBackboneで計測したデータは様々な形式でチャートを作成する事が出来ます。この記事ではBackboneテストの計測結果から均一性(標準偏差)を求める方法について扱います。
■均一性とは
均一性はレスポンスタイムのばらつきを示します。単位は秒。均一性が短時間である程、ばらつきが小さいので良いとされます。ばらつきが大きいサイトは、ある時は早くアクセスできるが、別の時には遅いと言う不快なUXになります。
■レスポンスタイムのばらつきが大きいサイトと小さいサイトの比較
このサンプルでは、ばらつきの大きいサイト(黄色の折れ線グラフ)とばらつきの小さいサイト(青色の折れ線グラフ)を例として平均応答時間のチャートを示します。一目瞭然ですが、ばらつきの大きいサイトは10秒以下の応答時間や60秒近い応答時間があるのが分かります。
■均一性(Standard Deviation|標準偏差)チャート
上記の折れ線グラフのデータに基づいて均一性、Standard Deviationチャートを表示するとこのサンプルのようになります。それぞれの棒グラフにマウスを移動すると均一性のデータが表示されます。このサンプルでは青色の棒グラフが0.291秒、黄色の棒グラフが6.873秒を示しました。
■均一性、Standard Deviationチャートの表示方法
Backboneテストの計測結果から均一性、Standard Deviationチャートを作成する方法は上手の手順で可能となります。
■均一性とは
均一性はレスポンスタイムのばらつきを示します。単位は秒。均一性が短時間である程、ばらつきが小さいので良いとされます。ばらつきが大きいサイトは、ある時は早くアクセスできるが、別の時には遅いと言う不快なUXになります。
■レスポンスタイムのばらつきが大きいサイトと小さいサイトの比較
このサンプルでは、ばらつきの大きいサイト(黄色の折れ線グラフ)とばらつきの小さいサイト(青色の折れ線グラフ)を例として平均応答時間のチャートを示します。一目瞭然ですが、ばらつきの大きいサイトは10秒以下の応答時間や60秒近い応答時間があるのが分かります。
■均一性(Standard Deviation|標準偏差)チャート
上記の折れ線グラフのデータに基づいて均一性、Standard Deviationチャートを表示するとこのサンプルのようになります。それぞれの棒グラフにマウスを移動すると均一性のデータが表示されます。このサンプルでは青色の棒グラフが0.291秒、黄色の棒グラフが6.873秒を示しました。
■均一性、Standard Deviationチャートの表示方法
Backboneテストの計測結果から均一性、Standard Deviationチャートを作成する方法は上手の手順で可能となります。
2011年2月18日金曜日
Active Backboneにおけるトランザクションの計測方法
GPNのBackboneでは、計測対象として一つのURL(シングルページテスト)か、一連のウェブ操作を記録し、そのそれぞれのURL毎に計測する事(トランザクションテスト)が可能です。ECサイトなどユーザーID、パスワードを入力するようなウェブページを計測するような場合や、シナリオに基づいて特定の画面遷移でのパフォーマンスを計測する場合(※)にはトランザクションテストを使用します。
※例えば、キャンペーンなどをインターネット広告などで告知し、そこから自社サイトのランディングページを経由して最終的に目的のページまでユーザーが画面遷移するシナリオを想定した場合に、ユーザーがどのようなUXであるかを確認するようなケースを想定してください。
■トランザクションテストの設定方法
ウェブ操作を記録するには、専用ツールのGomez Recorderを使ってトランザクションテスト用のスクリプト(GSLファイル)を作成します。Gomez Recorderのダウンロード、セットアップ、作成したスクリプトのアップロード方法、Backboneテストへの設定方法については、Gomez Recorderクイックスタートガイド(PDFファイル、806KB、画像が多いので少しファイルサイズが大きいです)を参照下さい。
■トランザクションテストとシングルテストの違い
トランザクションテストで計測した場合、平均応答時間やコンポーネントチャートなどはシングルページテストと相違はありませんが、計測点を選択した(ページブレークダウン)時に表示される結果が異なります。下図はトランザクションテストのページブレークダウン画面です。赤枠で囲まれた部分をシングルページテストのページブレークダウン画面と比較してみて下さい。シングルページテストではseq:0だけですがトランザクションテストではseq:0からseq:7迄あるのが分かります。これはトランザクションテストに登録されているURLがseq:0からseq:7迄の8URLであることを示しています。そして、その下に記されている数値が、各URLのレスポンスタイムを示しています。尚、このトランザクションテストのスクリプトをGomez Recorderで表示した場合のサンプルをGomez Recorderサンプルに示します。
■トランザクションテストのページブレークダウン画面
■シングルページテストのページブレークダウン画面
■Gomez Recorderサンプル
※例えば、キャンペーンなどをインターネット広告などで告知し、そこから自社サイトのランディングページを経由して最終的に目的のページまでユーザーが画面遷移するシナリオを想定した場合に、ユーザーがどのようなUXであるかを確認するようなケースを想定してください。
■トランザクションテストの設定方法
ウェブ操作を記録するには、専用ツールのGomez Recorderを使ってトランザクションテスト用のスクリプト(GSLファイル)を作成します。Gomez Recorderのダウンロード、セットアップ、作成したスクリプトのアップロード方法、Backboneテストへの設定方法については、Gomez Recorderクイックスタートガイド(PDFファイル、806KB、画像が多いので少しファイルサイズが大きいです)を参照下さい。
■トランザクションテストとシングルテストの違い
トランザクションテストで計測した場合、平均応答時間やコンポーネントチャートなどはシングルページテストと相違はありませんが、計測点を選択した(ページブレークダウン)時に表示される結果が異なります。下図はトランザクションテストのページブレークダウン画面です。赤枠で囲まれた部分をシングルページテストのページブレークダウン画面と比較してみて下さい。シングルページテストではseq:0だけですがトランザクションテストではseq:0からseq:7迄あるのが分かります。これはトランザクションテストに登録されているURLがseq:0からseq:7迄の8URLであることを示しています。そして、その下に記されている数値が、各URLのレスポンスタイムを示しています。尚、このトランザクションテストのスクリプトをGomez Recorderで表示した場合のサンプルをGomez Recorderサンプルに示します。
■トランザクションテストのページブレークダウン画面
■シングルページテストのページブレークダウン画面
■Gomez Recorderサンプル
2011年2月16日水曜日
もっと詳しく、Synthetic Monitoring - Backbone
Synthetic Monitoringについて、もう少し掘り下げてみたいと思います。この記事ではSynthetic Monitoring - Backboneテストについて扱います。尚、Synthetic Monitoringの概要については前の記事『Webパフォーマンスを計測するCompuware Gomez:Synthetic Monitoringソリューション』を参照下さい。
■Backboneで出来る事
Backboneは、ISPに設置したノードで動作するエージェント(疑似ブラウザ)から定期的に計測するテストです。ISP上のエージェントから計測しますのでノイズの少ないパフォーマンスデータを収集する事が可能です。企業トップページやエンドユーザーのマイページなど、常にどのような状態であるか把握しておきたい重要なページを計測対象として計測しておく事で、正常時がどのようなUXであるか、異常が何時から起きたのか、コンテンツを変更した時にどのような影響があったか、問題が生じた場合に原因を絞り込む事が出来ます。下記にBackboneテストの特色をリストアップします。
Backboneは、指定されたページの全てのオブジェクト(css/js/imageファイルなど、ページを構成する全ての要素)についてパフォーマンスを計測します。1回の計測毎に、対象のページに含まれる全てのオブジェクトに対して下記の項目を計測します。
■平均応答時間のサンプル
平均応答時間を折れ線グラフで示します。計測間隔が短い場合、より細かい折れ線グラフとなります。サンプルでは1時間に一度計測したデータを示しています。
■コンポーネントチャートのサンプル
平均応答時間のサンプルで示した折れ線グラフのデータを、その応答時間に含まれる要素毎に分解してグラフ化したチャートです。レスポンスタイム、DNSルックアップタイム、コネクションタイム、ファーストバイトタイム、コンテンツダウンロードタイム、SSLタイムがデータに含まれます。(HTTPS通信でない場合、SSLタイムはデータに含まれません。)
■ウォーターフォールチャートのサンプル
平均応答時間のサンプルの折れ線グラフの点毎に、このウォーターフォールチャートと書くオブジェクトの詳細リストを表示できます。このサンプルではページに含まれるオブジェクトの順に描画/表示されますが、この他にオブジェクトが置かれているホスト毎に描画/表示するウォーターフォールチャートもあります。
■Backboneで出来る事
Backboneは、ISPに設置したノードで動作するエージェント(疑似ブラウザ)から定期的に計測するテストです。ISP上のエージェントから計測しますのでノイズの少ないパフォーマンスデータを収集する事が可能です。企業トップページやエンドユーザーのマイページなど、常にどのような状態であるか把握しておきたい重要なページを計測対象として計測しておく事で、正常時がどのようなUXであるか、異常が何時から起きたのか、コンテンツを変更した時にどのような影響があったか、問題が生じた場合に原因を絞り込む事が出来ます。下記にBackboneテストの特色をリストアップします。
- 国内・海外のノード(150カ所)からの計測
- 計測するエージェントをInternet Explorer 6、IE7、FireFoxから選択可能
- 最小テスト間隔5分から計測可能
- 単一URLとトランザクションに対して計測可能
- 定期メンテナンス、一次メンテナンス期間中の計測停止
- 閾値に定めたレスポンスタイムを超える場合のアラート(他に3種類有り)
- 計測データを33日間保存
- トレンドデータを14ヶ月間保存
- 計測データをWebサービスやFTPで取得可能(データフィード機能)
- 競合サイトの計測も可能(パッシブタイプの計測)
Backboneは、指定されたページの全てのオブジェクト(css/js/imageファイルなど、ページを構成する全ての要素)についてパフォーマンスを計測します。1回の計測毎に、対象のページに含まれる全てのオブジェクトに対して下記の項目を計測します。
■平均応答時間のサンプル
平均応答時間を折れ線グラフで示します。計測間隔が短い場合、より細かい折れ線グラフとなります。サンプルでは1時間に一度計測したデータを示しています。
■コンポーネントチャートのサンプル
平均応答時間のサンプルで示した折れ線グラフのデータを、その応答時間に含まれる要素毎に分解してグラフ化したチャートです。レスポンスタイム、DNSルックアップタイム、コネクションタイム、ファーストバイトタイム、コンテンツダウンロードタイム、SSLタイムがデータに含まれます。(HTTPS通信でない場合、SSLタイムはデータに含まれません。)
■ウォーターフォールチャートのサンプル
平均応答時間のサンプルの折れ線グラフの点毎に、このウォーターフォールチャートと書くオブジェクトの詳細リストを表示できます。このサンプルではページに含まれるオブジェクトの順に描画/表示されますが、この他にオブジェクトが置かれているホスト毎に描画/表示するウォーターフォールチャートもあります。
2011年2月14日月曜日
Webパフォーマンスを計測するCompuware Gomez:Synthetic Monitoringソリューション
この記事ではGPNのサービスの一つで、Webサイトのパフォーマンスを計測するサービスであるSynthetic Monitoringについて扱います。Synthetic MonitoringにはISPから計測するBackboneと契約ユーザーのPCから計測するLastMile、ユーザーのPCから計測するPrivatePeerの三つのテストがあります。
LastMileは、世界各地の15万(国内600)を超える個人契約PC上で動作するFireFoxまたはIE6エージェント(疑似ブラウザ)から指定されたページ(シングルまたはトランザクション)に対して定期的にアクセスし、ページに含まれる全てのオブジェクトに関する処理時間を収集します。ファイヤーウォールの外側で最もエンドユーザーに近いデータを示します。従って、LastMileのデータはエンドユーザーが体験しているUXであると考える事が出来ます。
PrivatePeerは、リリース前のサイトを計測する為に利用したり、イントラネットの計測に利用可能です。
■まとめ
Backboneは、ネットワークに左右されない純粋なセンター側の性能を測定します。LastMileは、通信環境を加味した性能を測定します。BackboneとLastMileの計測結果を比較する事によって、ボトルネックをより明確に炙り出す事が可能になります。
Backboneは、150を超える計測ノード(日本国内ではNTTとKDDIの二つのノード)上で動作するFireFoxまたはInternet Explorerエージェント(疑似ブラウザ)から指定されたページ(シングルまたはトランザクション)に対して定期的にアクセスし、ページに含まれる全てのオブジェクトに関する処理時間を収集します。ISPに設置されたエージェントからの計測ですので、ファイヤーウォールの外側で最もノイズの少ないデータを示します。言い換えると、エンドユーザーは少なくともこれより早いUXを体験する事はありません。
PrivatePeerは、リリース前のサイトを計測する為に利用したり、イントラネットの計測に利用可能です。
■まとめ
Backboneは、ネットワークに左右されない純粋なセンター側の性能を測定します。LastMileは、通信環境を加味した性能を測定します。BackboneとLastMileの計測結果を比較する事によって、ボトルネックをより明確に炙り出す事が可能になります。
2011年2月10日木曜日
ユーザーエクスペリエンスの計測が必要とされる背景
■従来の方法はファイヤーウォールの内側しか計測できない
従来の監視方法や測定方法は、ブラウザからWebサーバーまでのEnd to Endを計測できないので、本当のユーザーエクスペリエンス(UX)を把握できていません。またHTTPWatchのようなツールを使い、社外から自社サイトへアクセスすると言った方法でUXを確認しているケースが考えられますが、定常的に計測しデータを収集し分析する事は多大なコストを必要とする為、実際にこのレベルで実践されているサイト管理者はごく僅かではないでしょうか。また、国内から自サイトを検証する事は可能であったとしても、世界各地からのUXを計測する事は大変困難ではないでしょうか。
■ブラウザとウェブサーバー間で殆どの時間が消費される
米国Yahoo!のパフォーマンス担当責任者である Steve Souders(スティーブ・サウダーズ)氏のハイパフォーマンスWebサイト-高速サイトを実現する14のルール(初版 A章 1ページより引用)によると『HTML文書をウェブサーバからブラウザへ取得してくるのに消費される時間は、エンドユーザーに対する応答時間(response time)の10%から20%以下に過ぎません。ウェブページの応答時間を劇的に削減したいのなら、待ち時間の80%から90%を締めるその他の部分に重点を置く必要があるのです。』とあります。これは、ウェブサーバーやバックエンドのシステムをいくらチューニングしても、ユーザーエクスペリエンス(UX)の改善は殆ど見込めない事を示しています。
■CSS/Web2.0/RIAの普及による影響が大きい
ブラウザ上でのレンダリングにかかる時間は、CSS/Web2.0/RIAの普及によってますます大きくなっていますが、ユーザはこれらのクライアント側の処理時間も含めて、サイトの応答速度であると認識してしまいます。また、マーケティング部門が管轄・更新するコンテンツの大きさは、低帯域のアクセス経路を使っているユーザの体感速度に大きく影響しますが、コンテンツの更新は頻繁にかつ迅速に行われなければならないので、殆どの場合、ユーザーに与える影響はベンチマーク・監視・管理されていないのが現状です。
■ブラウザが多様化している
Net Applicationsが調査したブラウザシェアによると、ブラウザの多様化によりInternet Explorerの占有率が低下し、サイト訪問者の44%がIE以外のブラウザを使用する状況が生じており、この傾向は更に進むと予想されています。このような環境においてブラウザの差によるUXの管理をワークフロー化している企業はごく僅かです。理想的にはサイト訪問者がどのブラウザでアクセスしているか、そのブラウザでどのようなUXであるかを把握した上でパフォーマンス改善を検討する事が有益です。
このような状況から、ファイヤーウォールの外側から計測するサービスのニーズが生まれてきました。
従来の監視方法や測定方法は、ブラウザからWebサーバーまでのEnd to Endを計測できないので、本当のユーザーエクスペリエンス(UX)を把握できていません。またHTTPWatchのようなツールを使い、社外から自社サイトへアクセスすると言った方法でUXを確認しているケースが考えられますが、定常的に計測しデータを収集し分析する事は多大なコストを必要とする為、実際にこのレベルで実践されているサイト管理者はごく僅かではないでしょうか。また、国内から自サイトを検証する事は可能であったとしても、世界各地からのUXを計測する事は大変困難ではないでしょうか。
■ブラウザとウェブサーバー間で殆どの時間が消費される
米国Yahoo!のパフォーマンス担当責任者である Steve Souders(スティーブ・サウダーズ)氏のハイパフォーマンスWebサイト-高速サイトを実現する14のルール(初版 A章 1ページより引用)によると『HTML文書をウェブサーバからブラウザへ取得してくるのに消費される時間は、エンドユーザーに対する応答時間(response time)の10%から20%以下に過ぎません。ウェブページの応答時間を劇的に削減したいのなら、待ち時間の80%から90%を締めるその他の部分に重点を置く必要があるのです。』とあります。これは、ウェブサーバーやバックエンドのシステムをいくらチューニングしても、ユーザーエクスペリエンス(UX)の改善は殆ど見込めない事を示しています。
■CSS/Web2.0/RIAの普及による影響が大きい
ブラウザ上でのレンダリングにかかる時間は、CSS/Web2.0/RIAの普及によってますます大きくなっていますが、ユーザはこれらのクライアント側の処理時間も含めて、サイトの応答速度であると認識してしまいます。また、マーケティング部門が管轄・更新するコンテンツの大きさは、低帯域のアクセス経路を使っているユーザの体感速度に大きく影響しますが、コンテンツの更新は頻繁にかつ迅速に行われなければならないので、殆どの場合、ユーザーに与える影響はベンチマーク・監視・管理されていないのが現状です。
■ブラウザが多様化している
Net Applicationsが調査したブラウザシェアによると、ブラウザの多様化によりInternet Explorerの占有率が低下し、サイト訪問者の44%がIE以外のブラウザを使用する状況が生じており、この傾向は更に進むと予想されています。このような環境においてブラウザの差によるUXの管理をワークフロー化している企業はごく僅かです。理想的にはサイト訪問者がどのブラウザでアクセスしているか、そのブラウザでどのようなUXであるかを把握した上でパフォーマンス改善を検討する事が有益です。
このような状況から、ファイヤーウォールの外側から計測するサービスのニーズが生まれてきました。
2011年2月8日火曜日
Compuware Gomez(旧Gomez Performance Network(GPN))とは?
この記事ではCompuware Gomez(旧GPN)を簡単にご紹介したいと思います。
※本記事は2011年5月27日にCompuware社のブランド統一に伴い内容を変更しております。
Compuware Gomez(旧GPN)とは、米国Compuware社が提供するアプリケーションパフォーマンス管理(ユーザエクスペリエンス管理)ソリューションのブランド名です。サイト訪問時のユーザー行動に重要な影響をあたえるパフォーマンス、品質、可用性を計測して視覚化するSaaS型のサービスです。Compuware Gomez(旧GPN)は、Webパフォーマンス計測、Webパフォーマンスビジネス分析、Webブラウザ互換性テスト、Web負荷・パフォーマンステストを実現する下記のサービスを含んでいます。
以下、修正前の内容となっております。
また2011年4月リリース予定のサービスActive Mobile XFが新たに加わります。このサービスはActive Monitoring Suiteに含まれるBackboneサービスに、モバイルサイトとアプリケーションに対するパフォーマンス計測を追加します。
※本記事は2011年5月27日にCompuware社のブランド統一に伴い内容を変更しております。
Compuware Gomez(旧GPN)とは、米国Compuware社が提供するアプリケーションパフォーマンス管理(ユーザエクスペリエンス管理)ソリューションのブランド名です。サイト訪問時のユーザー行動に重要な影響をあたえるパフォーマンス、品質、可用性を計測して視覚化するSaaS型のサービスです。Compuware Gomez(旧GPN)は、Webパフォーマンス計測、Webパフォーマンスビジネス分析、Webブラウザ互換性テスト、Web負荷・パフォーマンステストを実現する下記のサービスを含んでいます。
以下、修正前の内容となっております。
- Active Monitoring Suite=Webパフォーマンス計測
- Actual Experience XF=Webパフォーマンスビジネス分析
- Reality View XF=Webブラウザ互換性テスト
- Reality Load XF=Web負荷・パフォーマンステスト
また2011年4月リリース予定のサービスActive Mobile XFが新たに加わります。このサービスはActive Monitoring Suiteに含まれるBackboneサービスに、モバイルサイトとアプリケーションに対するパフォーマンス計測を追加します。
2011年2月7日月曜日
初めまして
このブログでは、株式会社サムライズが販売しているCompuware社のCompuwa Gomez(旧Gomez Performance Network(GPN)、2011年5月27日修正)について様々な情報を発信していく予定です。
サムライズでは、GPNをご紹介するウェブページを提供しておりますが、このブログではサムライズサイトで扱わない、GPNの使い方に関するちょっとしたコツや、良くあるお問い合わせをご紹介したいと思います。ご質問やご要望があればコメントへの書き込み、またはプロフィールにあるメールアドレスへご連絡下さい。お待ちしております。
サムライズでは、GPNをご紹介するウェブページを提供しておりますが、このブログではサムライズサイトで扱わない、GPNの使い方に関するちょっとしたコツや、良くあるお問い合わせをご紹介したいと思います。ご質問やご要望があればコメントへの書き込み、またはプロフィールにあるメールアドレスへご連絡下さい。お待ちしております。
登録:
投稿 (Atom)