HAR ファイルの生成と Web リクエストの分析
目的
HAR は HTTP Archive (アーカイブ) 形式の短縮形であり、Web ブラウザとサイトの間のすべてのやり取りのログを追跡します。
特に以下のような問題では、問題のトラブルシューティングに HAR ファイルが必要となる場合があります。
- パフォーマンスの問題: ページの読み込みに時間がかかる、特定のタスクを実行する際のタイムアウト
- ページのレンダリング: ページの形式が正しくない、情報が欠落している
このガイドでは、トラブルシューティングで最初に行うべき手順について説明します。この情報をサポート チームに提供することで、トラブルシューティングにかかる時間を短縮できます。
はじめる前に
「サポート対象プラットフォーム」のページを確認し、ブラウザがサポートされていることを確認してください。
比較のため、複数の HAR ファイルを生成することを強く推奨します。以下は、効果的な情報収集のためのガイドラインです。
- 影響を受けていないページ (パフォーマンスやページ レンダリングの問題が発生していないページ) の HAR ファイルを生成する。例: ダッシュボード、課題ビュー、課題検索およびプロジェクト ページ。
- 影響を受けたページの HAR ファイルを生成する。平均値を正確に取得し、一貫したタイミングを捉えるため、複数回生成することをおすすめします。
ソリューション
HAR ファイルの生成方法は、ご利用のブラウザによって次のように異なります。
Web リクエストの分析
HAR ファイルがキャプチャした Web リクエストの分析手順は、パフォーマンスの問題またはページ レンダリングの問題のトラブルシューティングによって異なります。
生成された HAR ファイルを表示する一般的なツールは、Web アプリケーションとして利用可能な HAR Viewer です。
パフォーマンスの問題のトラブルシューティング
パフォーマンスの問題では、読み込み時間と、ブラウザがユーザーにコンテンツを提供するための遅延の原因となっているリクエストに注意します。トラブルシューティングを効果的に行うには、Web リクエストに使用する定義を理解する必要があります。以下を参照してください。
以下は、 HAR Viewer または Google のツールである HAR Analyzer で読み込まれた HAR ファイルから抽出されたものです。
HAR ファイルの読み込み後に Web リクエストを強調表示すると、次の情報が表示されます。
Request start time since the beginning
ハイライトされたリクエストは、最初のリクエストから指定した時間後にコールされます。例: 以下の +6.32s は、現在のリクエストが、最初のリクエスト (ほとんどの場合、最初のリクエストとしての HTML リクエスト) の 6.32 秒後にコールされることを意味します。
Waiting
サーバーの応答を待機する時間。この値が高い場合、次のような可能性があります。
- ローカルでの待機時間が少ない場合、クライアントとサーバーの間のネットワークに問題があります。ネットワークのトラバースを阻害する要因にはさまざまなものが考えられます。クライアントとサーバーの間には多数のポイントがあります。それぞれが接続について独自の制限事項を持ち、問題の原因になる可能性があります。これを軽減するテストを行う最も簡単な方法として、アプリケーションを別のホストに移動させて待機時間が改善するかどうかを確認することが考えられます。
- サーバーがビジー状態か、サーバでパフォーマンスの問題が発生しています。次の画像では、サーバーからの応答の待機時間が 2 秒程度であることを確認できます。この例で影響していたのは複雑な JQL クエリでした。
問題が 1 日のうちの特定の時刻に発生している場合、発生時刻を記録して support.atlassian.com からサポート チケットを作成し、根本原因の調査を依頼してください。
Receiving
必要な情報をクライアントに転送するためにサーバーが使用した時間です。一般に、ここでネットワークの問題が検出されます。次の例をご確認ください。
この例の待機時間は 1.6 秒となっており、これがリクエストの完了を遅延させた大きな原因です。
DOM Loaded
DOM Loaded とは、ブラウザがすべての HTML を受信し、DOM ツリーへのパースを完了して、操作が可能になったことを示します。
ページが完全にレンダリングされる前に発生します (画像、CSS、JavaScript やその他のリンクされている外部リソースが完全にダウンロードされる必要がまだある可能性があります)。
これは onload イベントとは異なる点にご注意ください。
onload イベントはオブジェクトが読み込まれたときに発生します。onload は一般に <body> エレメント内で使用され、Web ページがすべてのコンテンツ (画像、スクリプト ファイル、CSS ファイルなど含む) を完全に読み込んだ後にスクリプトを実行します。
onload イベントを使用して、訪問者のブラウザのタイプやブラウザのバージョンを確認したり、情報に基づいて Web ページの適切なバージョンを読み込むことができます。
参照: http://www.w3schools.com/jsref/event_onload.asp
Page Loaded
ページを完全に読み込むのにかかった時間の合計 (Google analytics など、外部サーバーでデータを生成するための、Javascript での AJAX コールまたは REST コールを含みます)。
ページの完全な読み込みが完了するまでの間にページが白い場合、コンテンツが存在しないとは限りません。ページは一般に onload イベントの後に、外部コールからの情報を生成して表示されます。(読み込み時のダッシュボード ガジェットなど)
ページに含まれる外部リソース (ガジェット、外部リンクなど) がある場合、ページの完全な読み込みには時間がかかる可能性があります。所要時間は、サーバーのパフォーマンスよりも、他のサイト / サーバーからのリクエストの処理速度に応じて異なります。
サイズ
処理するリクエストのサイズもパフォーマンスの問題の原因の 1 つです。リクエストのサイズが遅延に与える影響を理解するための例を以下に示します。
2.4MB のデータの取得にかかる時間はどれぐらいでしょうか。次のように計算されます。
3 Mbps = 約 0.375MBps (注: B = バイト、b = ビット)
2.4 MB の取得に必要な時間:
2.4 MB / 0.375 MBps = 6.4 秒
これは利用可能なスループットによって異なります。一般に、スピード テストを実施し、一番近いサーバーからホストしているデータ センターまでのスループットを調べることができます。
上記の各ブラウザ タイプの [ネットワーク] タブから、同様のビューを表示できます。
上記の定義を明確に理解している場合、分析の手順は非常に簡単です。
- レスポンスに遅延があるリクエストを検索します (一般に、合計 Web リクエスト数を表示している中で一番長いバー)
- 最長の待機時間を持つリクエストと、実際の待機時間を特定します
- 遅延の主な原因を確認します (Blocking、Waiting、Receiving)
- ページを複数回リロードして問題が再現するかどうかを確認します
- 遅延の原因がサーバーであると特定された場合、取得した情報をサポート チームに提供してサポートを依頼します。その他の問題 (ネットワークなど) の場合、ご利用の ISP または社内のホスティング チームに直接サポートを依頼することをおすすめします。ここまでの手順で収集した情報を調査に活用できます。
レンダリングの問題のトラブルシューティング
ページのレンダリングに失敗する場合、開発者ツール の [ネットワーク] タブに原因が記録されていることが多くあります。原因が記録されていない場合、[キャッシュの無効化] の横のチェックボックスを選択してブラウザ キャッシュを無効化することをおすすめします。これにより、ブラウザでキャッシュ データを使用せずにページを最初からレンダリングできます。同様に、HAR ファイルのステータス コードも、問題の原因となるリクエストの特定に役立ちます。
コード 404 Bad Request
と共に [コンソール] タブに表示されるエラー メッセージの例:
{"errorMessages":["Error in JQL Query: Expecting either a value, list or function but got 'IN'. You must surround 'IN' in quotation marks to use it as a value. (line 1, character 11)"],"errors":{}}
This is found in the bug JRACLOUD-65837 - Creating a project using Reserved Words of JQL as project key breaks the new project navigation issue view which is also a page rendering issue
生成された HAR ファイルのステータス コードを判別することも重要です。以下に一般的な例をいくつか示します。
- 200 - 成功
- 404 - ページが見つかりません / 要求が正しくありません
- 401 - 認証されていません
- 403 - 禁止されています
- 304 - 変更されていません (コンテンツはキャッシュされています)
- 500 - 内部サーバー エラー
エラーの定義については、「HTTP/1.1 ステータス コードの定義」ページで詳細をご確認ください。
問題を発生させる動作で HAR ファイルを作成したら、その情報と再現手順をサポート チームに提供してください。確認された問題の背後にある根本原因をサポート チームが調査いたします。