Skip to content

MS_SlowFirstRequest

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

初回が遅い！

概要

初回が遅くなるケースの

  • 事例と
  • トラブルシュートの方法

についてまとめています。

アプリケーションの起動

CLRの周辺

ランタイムのロード

  • .NET Framework 自体のロード
    ファイルシステム・キャッシュ上に乗せるため、
    スタートアップ・スクリプトで.NETプログラムをキックする。
    （コールド スタート → ウォーム スタート化）
    • ウォーム スタート
      ウォーム スタートは、主要なCLRコンポーネント用のページの殆どが、
      既にメモリに読み込まれているときに発生し、貴重なディスク アクセス時間が節約されます。
      このため、マネージ アプリケーションを再度実行すると、初回よりも短い時間で起動します。
  • マネージ・プロセスのロード
    DLLのロード、GCスレッドの起動などがあるため。
    また、WPFの初期化はWindows Formsより遅い。

プリ・コンパイル

JITコンパイルと、NGen

※ .NET Core（MS_DotNetCore.md）からNGENは、ReadyToRun + Tiered Compilation（MS_ReadyToRunAndTieredCompilation.md）になるらしい。

補足（最新化）: 現行の .NET（.NET 5 以降）では NGen は使えず、 ReadyToRun（AOT プリコンパイル）＋ Tiered Compilation が標準。 起動時間をさらに詰めたい場合は Native AOT も選択肢になる。

プロセス起動の周辺

ミドルウェア類のプロセス起動に時間がかかっている可能性があります。

IIS、ASP.NET

ワーカ・プロセス起動からJITコンパイルまで、
以下の対応で解決する可能性があります。

Set objIE = CreateObject("InternetExplorer.Application")
objIE.Visible = False
objIE.Navigate("http://www.google.com/")
WScript.Sleep(5000)
objIE.Quit()

補足: このスクリプトは Internet Explorer の COM オートメーションを前提としており、 IE のサポート終了（2022年6月）により現行環境では動作しない。 同等のことは PowerShell の Invoke-WebRequest や curl で行う。

DBMS

DBMS関連を参照。

UI初期化の周辺

UIコントロールの初期化、描画によるチラつき

画面上に表示されるUIコントロールが多い場合のUIコントロールの初期化
（この問題はWPFなどでも解決していないが、描画回数は少なく抑えられる）

初期化データ取得

  • 画面表示時のデータ取得ラウンド・トリップ
    ファサードパターンなどを取り入れておらず、
    クライアント・サーバ間のラウンド・トリップが問題になることがある。

DBMS関連

キャッシュ

DBアプリケーションでは、DBMSの持つデータがキャッシュに上がるまで
I/O処理時間がかかるため、初回起動時の性能が遅く感じられるケース。

  • 分析方法としては、ディスクIOを確認する。

    • パフォーマンス カウンタ
    • SQLプロファイラ（SQLトレース）（MS_SQLProfiler.md）

  • この場合、

    • SQLのDMLを流すか、
    • UI操作をシミュレーションする類のツールのスクリプト、若しくはリクエストを流すか、

    することで、迅速にキャッシュにデータが上がるようにします。

統計情報の自動作成

統計情報の自動作成によって、初回実行が遅くなることがあるようです。

ネットワーク関連

通信パケットを覘く

基本的に「つながらない！」に記載された方法で確認する。

HTTP

HTTP電文を覘く

基本的に「つながらない！」に記載された方法で確認する。

プロキシの自動検出

プロキシを自動検出している場合に遅い事例がありました。
IEの「インターネットオプション」→「接続」タブ→「自動構成」→「設定を自動的に検出する」

※ 現行の Windows では「設定 > ネットワークとインターネット > プロキシ > 設定を自動的に検出する」に相当。 WPAD による自動検出が失敗するとタイムアウト待ちが発生するのは同じ。

SSL

SSLハンドシェークが問題になるケースがあります。

HTTP Keep Alive

HTTP 遅すぎる原因はHTTPSのSSLハンドシェーク - マイナビニュース

この問題の解決方法にHTTP Keep Alive設定があります。
サーバ・クライアントの双方に、HTTP Keep Alive設定が可能です。

証明書失効リスト (CRL)

証明書失効リスト (CRL)にアクセスできないときに遅い場合があります。

こちらは、SSL（HTTPS）接続に限らず、
デジタル署名されたプログラムの検証等のタイミングでも動作します。

  • FIX: A .NET Framework 2.0 managed application that has an Authenticode signature takes longer than usual to start（KB936707）

補足: .NET Framework 4.x 以降では、generatePublisherEvidence を無効化する、 あるいはネットワーク分離環境では CRL / OCSP のタイムアウトを短縮する運用で回避する。

LDAP

LDAPアクセスに使用しているAPI（ADSI）は、

ADのスキーマ更新やDC再起動後に
ADのスキーマキャッシュ情報が
クライアントにダウンロードされる仕様であり、

このトラフィックにより時間がかかることがある。

その他

リトライ処理

svnコマンド

「初回が」と言う訳では無いですが、

  • SubversionクライアントのsvnコマンドをASP.NET（IIS）の
    Network Serviceアカウントから実行すると遅くなるという現象があった。

  • パケット・キャプチャを行うと、

    • svnのクライアントがコマンド入力を受けてから
    • svnのサーバに対してリクエストを投げる間

    のsvnクライアント側で遅くなっていることを確認できた。

  • このため、svn.exe内部で問題が起きていると考え、
    ProcessMonitor（障害対応に使用するツールの一覧）を使用してプロセス内を確認すると、

    C:\Documents and Settings\Default User\Application Data\Subversion

    以下にアクセスし、アクセス拒否＋リトライを繰り返している事が確認できた。

  • 解決のため、上記のフォルダに、IIS_WPGグループの
    アクセス許可を付与した所、速く動作するようになった。

  • 参考：サービス・タスク系のアカウント問題（MS_ServiceAndTaskAccountIssues.md）

Tags: あるある, 障害対応, 性能, デバッグ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally