9

私は Azure からの CDN をかなり試しましたが、Web ロールを使用してセットアップが成功した後、自宅で安全だと思いました。

なぜ Web ロールなのか?

さて、通常のブロブの方法では取得できなかった圧縮とキャッシュヘッダーの利点が欲しかったのです。そして追加のボーナスとして; 大文字と小文字を区別する制約も削除されました。

CDN サービスの選択で十分です。以前はすべてのコンテンツが同じドメインから提供されていましたが、現在はほぼすべての「静的」コンテンツを cdn.cuemon.net から提供しています。理論的には、これによりパフォーマンスが向上するはずです。これは、ブラウザーの並列処理によってコンテンツ収集が 1 つのドメインのみに比べて「複数の」ドメインに分散されるためです。

残念ながら、これはパフォーマンスの低下につながりました。これは、コンテンツが提供される前のホブの数に関係していると思われます (tracert コマンドを使用):

C:\Windows\system32>tracert -d cdn.cuemon.net

Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    21 ms    21 ms    21 ms  87.59.99.217
  3    30 ms    30 ms    31 ms  62.95.54.124
  4    30 ms    29 ms    29 ms  194.68.128.181
  5    30 ms    30 ms    30 ms  207.46.42.44
  6    83 ms    61 ms    59 ms  207.46.42.7
  7    65 ms    65 ms    64 ms  207.46.42.13
  8    65 ms    67 ms    74 ms  213.199.152.186
  9    65 ms    65 ms    64 ms  94.245.68.160

C:\Windows\system32>tracert cdn.cuemon.net

Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    21 ms    22 ms    20 ms  ge-1-1-0-1104.hlgnqu1.dk.ip.tdc.net [87.59.99.217]
  3    29 ms    30 ms    30 ms  ae1.tg4-peer1.sto.se.ip.tdc.net [62.95.54.124]
  4    30 ms    30 ms    29 ms  netnod-ix-ge-b-sth-1500.microsoft.com [194.68.128.181]
  5    45 ms    45 ms    46 ms  ge-3-0-0-0.ams-64cb-1a.ntwk.msn.net [207.46.42.10]
  6    87 ms    59 ms    59 ms  xe-3-2-0-0.fra-96cbe-1a.ntwk.msn.net [207.46.42.50]
  7    68 ms    65 ms    65 ms  xe-0-1-0-0.zrh-96cbe-1b.ntwk.msn.net [207.46.42.13]
  8    65 ms    70 ms    74 ms  10gigabitethernet5-1.zrh-xmx-edgcom-1b.ntwk.msn.net [213.199.152.186]
  9    65 ms    65 ms    65 ms  cds29.zrh9.msecn.net [94.245.68.160]

上記のトレース ルートからわかるように、すべての外部コンテンツはかなりの時間遅延しています。Azure サービスは北ヨーロッパでセットアップされており、私はデンマークに定住していることに注意してください。

もう 1 つの問題は、web-role が 2 つの非常に小さいインスタンスであることです。2 つの小さなインスタンスを試す時間はまだありませんが、Microsoft が超小型インスタンスを 5Mb/秒 WAN に制限していることは知っています。

これがCDNにも当てはまるかどうかはわかりません。

とにかく - どんな助けや説明も大歓迎です。

そして、私は Azure プラットフォームに非常に満足していることを述べさせてください。

アップデート

-d オプションなしの新しい tracert。

user728584に触発されて、この記事を調査して見つけました。 pages-in-asp-net-caching-content-from-hosted-services.aspx、公開キャッシュ制御と CDN に関してさらに調査します。

これは過剰なホップ カウント現象を説明するものではありませんが、熟練したネットワーク プロフェッショナルがこの問題を明らかにする手助けをしてくれることを願っています。

ご安心ください、私の調査結果に基づいてお知らせします。

4

2 に答える 2

4

さて、パブリック キャッシング コントロールヘッダーを実装した後、CDN は期待どおりの動作をしているように見えます。CDN クラスター内の x 個のノードからコンテンツを配信します。

上記には、それが経験されているという制約があります-具体的な検証のために測定されていません。

ただし、このリンクは私の理論をサポートしています: http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3、

BLOB の有効期限 (TTL) 設定は、CDN エッジ サーバーが BLOB ストレージ内のソースからの新しいコピーを要求する前に、キャッシュされたリソースのコピーを返す時間を制御します。この期間が過ぎると、新しいリクエストによって CDN サーバーは元の BLOB からリソースを再度取得するよう強制され、その時点で再度キャッシュされます。

これは私の想定された課題でした。CDN 参照リソースは、元の BLOB をプールし続けました。

また、このリンクにもクレジットを表示する必要があります (user728584 が提供)。http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content- from-hosted-services.aspx。

そして今のところ最後のリンク: http://blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx

ASP.NET ページの場合、既定の動作は、キャッシュ コントロールを private に設定することです。この場合、Windows Azure CDN はこのコンテンツをキャッシュしません。この動作をオーバーライドするには、Response オブジェクトを使用してデフォルトのキャッシュ コントロール設定を変更します。

したがって、この小さなパズルに対するこれまでの私の結論は、キャッシュ制御に細心の注意を払う必要があるということです (これは明らかな理由でプライベートに設定されることがよくあります)。Web ロール アプローチをスキップすると、TTL はデフォルトで 72 時間になります。したがって、すぐに使用できます。

私を正しい方向に向けてくれたuser728584に感謝します。

于 2012-04-27T11:13:46.543 に答える
4

明らかなことは言いませんが、tracert テストを行ったときにコンテンツが CDN キャッシュから削除されず、Blob Storage から提供されないように、Cache-Control HTTP ヘッダーを多数に設定していると思いますか?

近くにかなりの数のエッジ サーバーがあるので、パフォーマンスが向上することを期待しています 。

Maarten Balliauw は、CDN の使用法とユース ケースに関する優れた記事を公開しています (これは役立つでしょうか?): http://acloudyplace.com/2012/04/using-the-windows-azure-content-delivery-network/

それがまったく役立つかどうかはわかりませんが、興味深い...

于 2012-04-25T00:05:56.977 に答える