4

Web 応答を生成するルックアップテーブルがたくさんあります。

IIS と Asp.net を使用すると、応答を非常に高速に処理するために使用できる静的ルックアップテーブルをメモリに保持できると思います。

しかし、同じことができる.net以外のソリューションもありますか?

私は fastcgi を見てきましたが、これは X プロセスを開始し、誰でも Y リクエストを処理できると思います。しかし、プロセスは定義上、互いにシールドされています。1 つのプロセスのみを使用するように fastcgi を構成できますが、これはスケーラビリティに影響しますか?

cgi または fastcgi にバインドされているため、PHP またはその他のインタープリター言語を使用するものは動作しません。

memcacheがオプションになる可能性があることは理解していますが、これには別の（ローカル）ソケット接続が必要になりますが、メモリ内のすべてがはるかに高速になるため、避けたいと思います。

このソリューションは、Windows または Unix で動作します... あまり重要ではありません。唯一重要なことは、大量のリクエスト (現在は 100/秒、1 年で 500/秒に増加) が発生することであり、それを処理するために必要な Web サーバーの量を減らしたいと考えています。

現在のソリューションは、PHP と memcache (および SQL サーバー バックエンドへの時折のヒット) を使用して行われます。Apache は高速ですが (とにかく php の場合)、50/秒を超えると実際の問題が発生します。

賢明な選択をするのに十分な回答がなかったので、私はこの質問に賞金をかけました.

現時点では、Asp.net または C(++) を使用した fastcgi のいずれかを検討しています。

4

2 に答える 2

5

Redisのようなメモリ内のキー値データストアを使用する必要があるように思えます。将来的に複数の Web サーバーを使用する予定がある場合は、集中型のメモリ ストアを確実に使用する必要があります。Redis は、リスト、セット、順序付きセットなどの高度なデータ構造をサポートするため、このシナリオでは特に理想的です。また、非常に高速で、エントリ レベルの Linux ボックスで 110000 SETs/秒、81000 GETs/秒を取得できます。ベンチマークを確認してください。そのルートをたどると、アクセスを簡素化できるc# redisクライアントがあります。

共有メモリを使用するには、同じプロセスで「常に実行中」のアプリケーション サーバーが必要です。このような場合、静的クラスまたは共有「アプリケーション」キャッシュを使用できます。最も一般的な「アプリケーション サーバー」は、Java サーブレット コンテナー (Tomcat など) または ASP.NET です。

ディスクではなくメモリにアクセスするように移行すると、パフォーマンスが大幅に節約されます。このパフォーマンスが重要な場合は、インタープリター言語の使用を検討したくないと思います。リクエスト、ネットワーク IO、ワーカー スレッドのセットアップ プロトコルの解析などを処理するときは、常にオーバーヘッドが発生します。アウト プロセス (同じホスト上にある) 共有メモリ ストアを使用する決定は、イン メモリ ストアと比較して無視できます。要求を完了するのにかかる全体の時間との比較。

于 2010-02-19T08:50:52.950 に答える
1

まず第一に、あなたの直接の質問について考えさせてください:

- あなたが目指しているパフォーマンスについては、ルックアップ テーブルへの共有メモリ アクセスを要求するのはやり過ぎだと思います。たとえば、memcache 開発者は期待されるパフォーマンスについて次のように述べています。

- 現在、すべてのページを動的に生成しているため、おそらく CPU 時間によって制限されています。可能であれば、キャッシュ、キャッシュ、キャッシュ！フロントページをキャッシュして、1 分または 5 分に 1 回だけ再構築します。ログインしたユーザーの場合、セッションで再びアクセスする可能性があるユーザー固有のページをキャッシュします。例: 1 秒あたり 50 リクエストが動的なページにとってそれほど悪くない場合、かなり平凡なサーバーで毎秒数千の静的ページ。私の最善のヒントは、 varnishまたはsquidを使用してリバース プロキシを設定することです。

- まだ多くのページを動的に生成する必要がある場合は、php アクセラレータを使用して、スクリプトを実行するたびに php コードをコンパイルする必要がないようにします。ウィキペディアによると、これは 2 倍から 10 倍のパフォーマンスの向上です。

- mod_php は、php を実行する最速の方法です。

- fastcgi を使用する以外に、apache モジュールを作成して、データを Web サーバー自体と共有メモリ空間に置くことができます。これは非常に高速である可能性があります。ただし、パフォーマンスを向上させるためにこれを行っている人は聞いたことがなく、非常に柔軟性のないソリューションです。

- より静的なコンテンツに移行するか、fastcgi を使用する場合: lighthttpdは apache よりも高速です。

- まだ十分に速くありませんか? TUXなどのカーネル内 Web サーバーは非常に高速です。


第二に、この難題に遭遇したのはあなたが最初ではありません。幸いなことに、大型の魚の中には親切にも彼らの「トリック」を私たちと共有してくれる人がいます。これはあなたの質問の範囲を超えていると思いますが、これらの人がどのように問題を解決したかを見るのは本当に刺激的であり、私が知っている資料を共有することにしました. Facebook のアーキテクチャに関するこのプレゼンテーションと、「スケーラブルな Web サービスの構築」に関するこの

プレゼンテーションを 見てください。このプレゼンテーションには、flickr の設計に関するメモが含まれています。

さらに、facebook には、彼らが開発して貢献した印象的なツールセットがリストされています。さらに、彼らはアーキテクチャに関するメモを共有しています。パフォーマンスを改善するいくつかのトリック: - memcache-over-udp などのmemcache
のパフォーマンスを改善するカスタマイズ。 - hiphopは、php-to-optimized-c++ コンパイラです。Facebook のエンジニアは、CPU 使用率が 50% 削減されたと主張しています。 - 「より高速な言語」で計算集約型のサービスを実装し、thriftを使用してすべてを結び付けます。



于 2010-05-04T23:29:34.817 に答える