nginxとmemcachedはどの程度連携して機能しますか？

Glassfishアプリサーバークラスターで実行されているJava EEベースのWebアプリケーションがあります。着信トラフィックは、主にアプリケーションリソースのXMLベースの表現に対するRESTfulリクエストですが、おそらくトラフィックの5％はJSONまたはXHTML / CSSベースの表現に対するものです。

現在、クラスター内のGlassfishインスタンス全体に着信トラフィックを分散するための負荷分散ソリューションを調査しています。また、memcachedを使用してクラスターをオフロードする方法も検討しています。memcachedは、キーがRESTリソース名（たとえば、「/ user / bob」、「/ group / jazzlovers」）であり、値が対応するXML表現。

有望と思われるアプローチの1つは、1石で両方の鳥を殺し、軽量で高速なnginx HTTPサーバー/リバースプロキシを使用することです。Nginxは、最初にmemcachedでURIを調べて、期限切れになっていないXML表現が既にあるかどうかを確認することにより、各着信要求を処理します。そうでない場合、nginxはGlassfishインスタンスの1つにリクエストを送信します。nginx memcachedモジュールについては、この短い記事で説明しています。

nginxとmemcachedをこのように使用した場合の全体的な印象はどうですか？それらについて学ぶのに最も役立つリソースは何ですか？あなたがそれらを試したが、それらがあなたの目的に合わなかったなら、なぜそうではなく、代わりに何を使いましたか？

注：ここに関連する質問があります。ServerFaultについて知る前に、StackOverflowでこれを尋ねました。

編集：ここまでのすべての回答は、直接的な経験はありませんでしたが、非常に役立ちました。最終的にこの答えはStackOverflowに表示され、nginx / memcachedの設定ではかなり強気でした。

Webサーバーの前にキャッシュサーバーを使用する必要があります。ワニスキャッシュをお勧めします。スカンジナビアで最大かつ最も忙しいウェブサイトで仕事でそれを使用します。13個の高負荷のイカボックスを1個のワニスボックスと1個のスペアボックスに交換しました。

プライベートWebサイトで簡単なアプリのベンチマークを行いましたが、1秒間に9件のリクエストから2000件以上になりました。

メモリ内の物を保持する期間を決定し、時間の終わりまで実行してから、データが変更されたときにキャッシュサーバーにhttpパージリクエストを送信するだけです。

私の個人的な意見では、経験から、ロードバランサーを使用している場合は、そのボックスを完全にロードバランシング機能に制限したいという意見があります。キャッシュからでもロードバランサーにコンテンツを提供させると、高負荷の状況下でロードバランシング機能が低下します（より多くの接続が長時間アクティブになり、全体的な容量とスループットが低下します）。

アプリ自体にルックアップを実行させ、キャッシュされたコンテンツを提供し、ロードバランサーに任せることをお勧めします。とはいえ、nginxはロードバランシングに関しては完璧ではありません。非常に基本的なラウンドロビンアルゴリズムのみを提供します。代わりにhaproxyをお勧めします。SSL復号化サービスを前もって必要とする場合、nginxはhaproxyの前でうまく動作します、私の経験では。

負荷分散、高可用性などが必要になる場合は、行き止まりになると思います。

また、そのような状況を考慮してください。ユーザーが認証されているときは、ページの外観が異なっており、ユーザーごとに追加機能が利用可能で個別化されています。URLはリンクなどの利便性のために同じです。たとえば、認証されたユーザーがコメントのために自分の名前/ captchaを入力する必要のないサイトや、uがログインしているときにサイトにユーザー名が表示されます（serverfaultのように）。このような場合、認証されたユーザーと認証されていないユーザーを区別できないため、nginxは使用できなくなります。

SSLが必要ない場合は、Varnishを実行することをお勧めします。Webサーバーやプロキシではなく、HTTPアクセラレータとして設計されています。SSLが必要な場合、varnishはSSLを処理できないため、nginxをSSLアクセラレーターとして実行し、ニスをプレーンHTTPアクセラレーターとして実行します。

キャッシングサーバーの選択はアプリケーション固有であり、アプリの詳細な分析がなければ、それについて一般的なコメントをすることはできないと思います。

私の選択はhaproxyです。非常に小さく、非常に高速なリバースプロキシですが、キャッシュプロキシではありません！キャッシュシステム「Squid Web Proxy」に使用します

CACHE /squid/ -> Load-balancing /Haproxy/ -> WEB I /lighttpd/
                                          -> WEB II /lighttpd/
                                          -> WEB III /lighttpd/

これは私のWebシステムに最適です