わかりました、これはかなり非科学的な質問です。事前に申し訳ありません。コードを公開（またはアップグレード）した後、Windows Azure（およびできればSQL Azureデータベース）を使用していて、本当にランダムなパフォーマンスの問題が発生している人はいますか？
私が見ているのは、公開後最大24時間である可能性もあります。これは一般的なレイテンシーです。http（s）リクエストは、返されるまでに非常に長い時間がかかります（30秒-1分）が、同じリクエストが次に呼び出されたときにミリ秒単位で返される可能性があります。
非常にランダムに見えます。何を変更する必要があるかを紺碧にするためにコードを公開するときはどうなりますか？負荷分散、DNSキャッシュ、IPアドレスなど、これらすべてのネットワーク層の変更の伝播が問題の原因になっている可能性がありますか？
ところで、ほとんどすべての場合、ステージング環境をアップグレードしてから、VIPを本番環境にスワップします。
これは主にあなたのウェブの役割に関係していますか？彼らは.NETコードを実行していますか？（ASP.NET？、WCF？など）
その場合、アクティビティが原因でリサイクルされたIISアプリケーションで通常の.NETJIT遅延を処理している可能性があります。この症状は、ASP.NETアプリをオンサイトに置いていて、しばらくの間それをヒットしない場合と同じように聞こえます。IISワーカーはリサイクルされ、ランタイムは新しいHTTPリクエストが着信するまでアプリをJITコンパイルしません。これにより、最初のリクエストが「永久に」かかる可能性がありますが、次の数分で着信するすべてのリクエストは「あなたがあなたのコードから期待するように、インスタント」。
これはAzure固有ではありませんが、オンサイトで実行しているものとは異なるIIS環境を処理している可能性があります（デフォルトのアプリプールのリサイクル設定/リサイクル後のウォームアップ設定に関して）。
提案で編集
ウォームアップに関連していると思われる場合は、いくつかの解決策があります。
（特に必要がない限り）最善の方法は、IISがアプリプールをリサイクルするという根本的な原因を管理することです。既定では、これはタイマーまたは要求カウントで発生します（Azureのどちらかはわかりません）。これがweb.configで発生した場合は、<recycling></recycling>要素を使用してオーバーライドできます。IIS.netには、これらの設定の最良の説明があります。を見てみましょう：
http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/recycling
それが役立つかどうかを確認します。打撃を受けていない時間帯（深夜など）に、時間制限のあるリサイクルを行うことをお勧めします。
もう1つのオプションは、トラフィックが継続的にサイトに到達するようにすることです。ある種のポーリングソフトウェアを使って。pingdomのような「稼働時間/ステータス」モニターはこれに最適です。これはハックアプローチですが、以前は奇妙なシナリオで使用していました。（お勧めしません）
特別な起動要件のためにそれが機能しない場合（これはあなたが持っていないように聞こえます）、IISにはウォームアップモジュールがあり、C＃4.0には役立つウォームアップクラスがあります。繰り返しになりますが、起動時ではなく、起動時に何が発生するかを確実に制御する必要があります。