静的コンテンツ用のサーバーを作りたいのですが。
3〜10 MBのファイルをいくつか提供する必要があります。 (私はこのサーバーにいくつかの.jsと.cssと私のウェブサイトからの画像も配置します)。
私はnginxとG-WANについて考えました( http://trustleap.com/ )。
わからないのは、静的コンテンツを提供するために必要なリソースは何ですか? RAMは各ファイル転送にどのくらい使用されますか?
256 mb(または512 mb)のVPSで適切なポートと巨大なバンドを使用すると、何秒/秒(3-10 mbファイル)のサービスを提供できますか? (私は「依存する」ことを知っていますが、経験または理論に基づいて大まかな見積もりを教えてください)。
ファイルが多くなく、頻繁にダウンロードされるだけです-キャッシュを検討する必要がありますか、それともヒットを処理するために必要な私のメモリのみを使用しますか?
Nginxを使用している場合は、アクティブな接続ごとに数KBのオーバーヘッドだけを話していることになります。 Apacheのようなものを使用している場合、接続ごとに1つのスレッドがあります。これは、接続ごとに数百KBまたはメガバイトになることもあります。
ただし、nginxはLinuxでは非同期disk IOをサポートしていません(Linuxの非同期ディスクIOは基本的に設計上ひどく壊れているため)。そのため、ディスクの読み取りごとにワーカープロセス全体がブロックされる可能性があるため、多くのnginxワーカープロセスを実行する必要があります。 FreeBSDを使用している場合、これは問題ではなく、nginxは非同期ディスクとネットワークIOで不思議に機能します。しかし、このプロジェクトにLinuxを使用している場合は、Apacheを使い続けることをお勧めします。
しかし、実際には、最も重要なことは、選択したWebサーバーではなくディスクキャッシュです。多くの空きRAMが欲しいので、OSはそれらのファイルをキャッシュし、読み取りを非常に高速にします。 「ホットセット」が8 GBを超える場合は、コスト/メリットの比率が高くなる可能性が高いため、代わりにRAMを少なくして、安価なSSDを入手することを検討してください。
最後に、CDNを使用してこれをオフロードし、非常に安価なサーバーを入手することを検討してください。静的ファイルを提供することは彼らがすることであり、彼らはそれを非常に速くそして非常に安価に行います。 SimpleCDNは最低価格ですが、MaxCDN、Rackspace、AmazonなどはすべてCDNスペースの下限で大きなプレーヤーです。
コンテンツのホットな部分をOSがRAMにキャッシュできる場合、OSはディスクを使用せず、非常に迅速にサービスを提供します。 1秒あたり数百のリクエストがVPSで可能になるはずです。CPU制限に達する前に、ネットワークを十分に飽和させてしまう可能性があります。
コンテンツがRAMに収まらない場合、ディスクIO(シーク、スループット、ファイルシステムの断片化))が作用し、方程式が変化します。
ウェブサーバーはクライアントごとにメモリのオーバーヘッドを追加しますが、nginxは接続ごとに数キロバイトでそれを行うことができます。
これらの指針がお役に立てば幸いです。
静的コンテンツを提供するにはどのようなリソースが必要ですか? RAMは各ファイル転送にどのくらい使用されますか?
まず、同じ数のワーカーに対して、G-WAN v4.7 +は起動時にNginxよりもはるかに少ないRAM:
_> Server 'nginx' process topology:
---------------------------------------------
6] pid:21228 Process RAM: 0.77 MB
5] pid:21229 Process RAM: 2.44 MB
4] pid:21230 Process RAM: 2.44 MB
3] pid:21231 Process RAM: 2.44 MB
2] pid:21232 Process RAM: 2.44 MB
1] pid:21233 Process RAM: 2.44 MB
0] pid:21234 Process RAM: 2.44 MB
---------------------------------------------
Total 'nginx' server footprint: 15.39 MB
> Server 'gwan' process topology:
---------------------------------------------
6] pid:6054 Thread
5] pid:6053 Thread
4] pid:6052 Thread
3] pid:6051 Thread
2] pid:6050 Thread
1] pid:6049 Thread
0] pid:5839 Process RAM: 2.19 MB
---------------------------------------------
Total 'gwan' server footprint: 2.19 MB
_
G-WANはスレッド(通常はコアごとに1つ)を使用し、Nginxはプロセス(通常はコアごとに1つ)を使用し、プロセスはより多くのオーバーヘッドをドラッグし、共有メモリを介した同期を必要とします。どちらもイベント処理の「非同期」モデルを使用します。
ここで注意してください G-WANは自動的に100万を超える同時接続に拡張できますが、Nginxはその_worker_connections
_設定 ( ab.c 上記のテスト)。
接続ごとにメモリのオーバーヘッドがあるかどうか、つまり、nginxまたはgwanがすべてのヒットでメモリを消費するかどうかは、私にはわかりません。
短い話は、G-WAN v4.7 +(デフォルトではメモリ内キャッシュが無効になっている)は、すべてのファイルサイズでRAM Nginxよりも消費量が少ないが、1秒あたりの要求の処理数が多い) 。
長い話は、Nginxは新しいHTTPキープアライブリクエストでもメモリをますます消費する一方で、G-WANのメモリ使用量はHTTPキープアライブリクエストに対して安定したままであり、Neepxがキープアライブ以外の場合よりはるかに大きくなることはありません。リクエスト。
weighttp wrapper ab.c は、テスト期間中のサーバーアプリケーションとシステムのメモリ消費量を測定します。そして、それはNginxがメモリリソースの消費に関してシステムに重い重みをかけることを示しています。
これは、各Webサーバーがリクエストを処理し、メモリを割り当てる方法が原因です。
5 mbファイルのリクエストが同時に10件ある場合、これはファイルの提供に50 mbメモリが使用されることを意味しますか?たぶん+スレッドのメモリ(nginxまたはgwanがevey接続にスレッドを使用しているかどうかはわかりません)。
両方のサーバー(NginxとG-WAN)はsendfile()
を使用しているため、(アプリケーションではなく)カーネルがI/Oにリソースを割り当てています。
Webサーバーは引き続きリソースを割り当てますが、これはディスクI/Oをバッファリングするためではなく、各接続のコンテキストを維持するためです。
したがって、メモリ消費量は、合計ファイルサイズではなく、各sendfile()
呼び出しで送信されるファイルチャンクのサイズに依存します。
Totfileのサイズは、同時実行性が高い場合の長期に影響を与えますが、これは、カーネルがキャッシュする必要のあるチャンクの量が原因です。
これ以上質問があれば、G-WANに連絡してください。私たちはCDNのようなアプリケーションに多額の投資を行ってきました。