Generate HAR files and analyze web requests for Atlassian support
要約
HAR is an abbreviation for HTTP Archive, a file format that tracks a web browser's interactions with a site.
HAR files can be a requirement for troubleshooting issues, specifically for problems listed below:
- Performance Issues: slow page load, timeouts when performing a specific task
- ページのレンダリング: ページの形式が正しくない、情報が欠落している
Providing this information to the support team will help speed up troubleshooting.
はじめる前に
Please be sure to take note of the supported browser types for the relevant app:
- On-premise(Server/Data Center): Supported Platforms
- Cloud: Supported browsers for Atlassian Cloud apps
比較のため、複数の HAR ファイルを生成することを強く推奨します。以下は、効果的な情報収集のためのガイドラインです。
- Generate a HAR file for an unaffected page (without performance or page rendering issues)
- Examples: Dashboard, Issue View, Issue Search, and Project page in Jira
- Generate a HAR file for an affected page
- Generate multiple times to get a better average and capture consistent timing
How to generate HAR files
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
サーバーの応答を待機する時間。この値が高い場合、次のような可能性があります。
- If the time waiting is low locally, then the network between your client and the server is the problem
- Any number of things could hinder the network traversal
- There are a lot of points between clients and servers; each one has its own connection limitations and could cause a problem
- The simplest method to test reducing this is to put your application on another host and see if the time waiting improves
- That the server is busy or suffering a performance issue
Below, we can see that there is around 2 second wait time from the server. This scenario was due to a complex JQL query:
問題が 1 日のうちの特定の時刻に発生している場合、発生時刻を記録して support.atlassian.com からサポート チケットを作成し、根本原因の調査を依頼してください。
Receiving
必要な情報をクライアントに転送するためにサーバーが使用した時間です。一般に、ここでネットワークの問題が検出されます。次の例をご確認ください。
この例の待機時間は 1.6 秒となっており、これがリクエストの完了を遅延させた大きな原因です。
DOM Loaded
DOM Loaded とは、ブラウザがすべての HTML を受信し、DOM ツリーへのパースを完了して、操作が可能になったことを示します。
ページが完全にレンダリングされる前に発生します (画像、CSS、JavaScript やその他のリンクされている外部リソースが完全にダウンロードされる必要がまだある可能性があります)。
Don't confuse with onload event.
The onload event occurs when an object has been loaded. onload is often used within the <body> element to execute a script once a web page has completely loaded all content (including images, script files, CSS files, etc.).
onload イベントを使用して、訪問者のブラウザのタイプやブラウザのバージョンを確認したり、情報に基づいて Web ページの適切なバージョンを読み込むことができます。
Please refer to: 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
It is essential to be able to identify the status code from the HAR files generated as well. Below are some common HTTP status codes:
- 200 - 成功
- 404 - ページが見つかりません / 要求が正しくありません
- 401 - 認証されていません
- 403 - 禁止されています
- 304 - 変更されていません (コンテンツはキャッシュされています)
- 500 - 内部サーバー エラー
エラーの定義については、「HTTP/1.1 ステータス コードの定義」ページで詳細をご確認ください。
After capturing consistent behavior, provide this information to the support team together with the steps taken for the Support team to work on the potential cause behind the observation.