ランブラーのようなサイトはどのようにして動的コンテンツをこれほど高速に配信しますか？Yahoo（私の国であるSEアジアにサーバーがあり、ランブラーにはありません）よりも高速です。
これは純粋にNginxの機能ですか？そのような機能について学ぶためにどこを調べるべきですか？
ここではかなり初心者です。Nginxから提供される場合、serverfault.comはIIS 7よりもはるかに高速になると考えています（どちらの場合もdbアクセス時間が同じであると仮定しています）。これは公正な仮定ですか？
編集：
IIS7の前でNginxを使用してKarlから投稿する
回答:
nginx内部の概要については、このプレゼンテーションをご覧ください。主な違いは、Apacheのようにスレッドを使用する代わりに、要求を非同期で処理することです。あなたは見ていて、このドキュメントを同様。
ランブラーのようなサイトはどのようにして動的コンテンツをこれほど高速に配信しますか？...これは純粋にNginxの機能ですか？そのような機能について学ぶためにどこを調べるべきですか？
これは、使用するWebサーバーとはほとんど関係ありません。nginx、IIS、Apacheはいずれも「十分に高速」で、一般に数ミリ秒以内に作業を完了します。nginxはApacheよりもはるかに高速ですが、これは単に、サイトの所有者がWeb提供部分に必要なサーバーの数が少なくなることを意味します。nginxはデータをより速く転送しません。
それほど重要ではない部分は、サーバー側の速度、つまりHTMLの作成にかかる時間です。より重要な部分は「フロントエンド」パフォーマンスです。つまり、HTML、CSS、Javascript、および画像、これらの数、これらのサイズ、およびこれらの適切な配信（HTTP圧縮、キャッシュ）を意味します。
もちろん、サーバー側の速度は依然として重要です。無視する必要があるとか、重要ではないとは言っていません。ただし、通常はエンドユーザーの速度を認識する最小の部分です。サーバー側の作業は500ミリ秒未満で行われることが多く、3,000〜5,000ミリ秒が経過する前にページの準備ができていません。この時間の大部分は、フロントエンドリソース（CSS、Javascript、画像）のダウンロードに費やされます。
スティーブ・スーダースは元の仕事をしていたが、ヤフーにいたとき、彼は現在Googleで働いている。彼の最初の本「高性能ウェブサイト」は、高速ウェブサイトの作成についてさらに学ぶための最良の出発点です。彼の本にある同じ資料は、このビデオトークとこれらのデザインルールで見つけることができます。しかし、この本はすぐに読むことができ、理解しやすいと思います。
WebPageTest.orgのテスターを使用してサイトを実行できます。これにより、これらのサイトのフロントエンド部分と、それらが高速または低速である理由をよく理解できます。
serverfault.comがNginxから提供される場合、IIS 7よりもはるかに高速になると考えています（両方のケースでdbアクセス時間が同じであると仮定します）。これは公正な仮定ですか？
いいえ、それは誤解です。:-)
Nginxは、完全なサーバーとして使用されるよりも、他のアプリケーション/サーバーの負荷分散や静的コンテンツの提供によく使用されます。
たとえば、多くのpythonフレームワークの1つを使用してアプリを記述し、nginxをその多くのインスタンスのフロントエンドにすることができます（おそらく複数のマシンに分散します）。この場合、nginxサーバーには2つの目的があります。画像やスタイルシートなどの静的コンテンツのリクエストを直接処理します（そしてその設計により、これを非常に迅速に行います）。 。これは、Ruby on Railsコミュニティでも非常に人気のある構成です。
RamblerがローカルのYahooサービスよりも速く表示される可能性のある理由は2つあります。まず、ローカルのYahoo PoPには、取得するリクエストの数を処理するのに十分なリソースがないため、ハードウェアを追加するだけで（ソフトウェアがこのように適切にスケールする場合）、速度が向上します（ただし、おそらく、違いはありません）追加のキットを維持するコストに見合った価値がなければ、Yahooがこれを行うことになります）。もう1つの大きな違いは、Webサーバーではなくバックエンドにある可能性があります。2つのサービスは、間違いなく非常に異なるデータベース配置を持ち、たとえそうでなくても、まったく同じ種類のクエリ（およびデータベースアーキテクチャ専用のハードウェアも大きな影響を及ぼします）。
あるサービスが別のサービスよりも高速である理由（一般的または特定の状況）を分析しても、通常、単一の単純な答えは得られません-数千のユーザーにスケールアウトすることを目的としたアプリを設計する方法は多数あります独自の利点、問題、妥協点、そしてそれらの違いをすべて考慮しても、各サイトは異なるユーザーベースの動的性を持ち、さらに設計者が制御できないネットワークの問題もあります。
ここに良い説明があります：http : //www.aosabook.org/en/nginx.html
私のルートではすでにEUでインスタントページがロードされているため、サーバー障害をはるかに高速に見るのに苦労しています（SOはおそらくトラフィックのためにロードに問題があるのでしょうか？）。これは、ほとんどのローカルニュースサイトなどよりもはるかに高速で応答が速いです。
ロード時間と遅延に関する明らかな問題のほとんどは、実際のサーバーのパフォーマンスではなく、サーバーとエンドユーザーのimoの間で発生します（誰かがサイズや設計に誤りがない限り）。さまざまなサイトをさまざまな方法でルーティングすることができ、国のローカルサイトは地球全体のものよりも大きな遅延がある可能性があります-それはすべて、サービスだけで解決できるとは言えないほど多くの変数に依存しています特定のuse（r）の問題がどこにあるかわからない限り、アップグレード/切り替え
サーバー上でのさまざまな種類のキャッシュが大きな違いを生むことは明らかですが、これらのサイトはすべて、私の知る限りではすでにそれを行っています。