タキシード、ワニス、イカ？
Apache Webフロントエンドサーバーの前に静止画像を配置するためのWebコンテンツアクセラレーターが必要です
以前のホスティングパートナーはTuxを使用して大きな成功を収めており、それが私たちが使用しているRed Hat Linuxの一部であるという事実を気に入っています。 ISPは、リバースキャッシングプロキシの役割でSquidを使用することを推奨しています。
TuxとSquidの間で何か考えはありますか？互換性、信頼性、および将来のサポートは、パフォーマンスと同様に私たちにとって重要です。
また、ここでワニスについて他のスレッドを読みました。トラフィックの多い環境でSquidやTuxと比較して、ワニスの実際の経験を持っている人はいますか？
乾杯
イアン
更新：現在Squidをテストしています。 abを使用して100の同時実行性で同じイメージを10,000回プルすると、Apache自体とSquid/Apacheの両方がリクエストを非常にすばやく焼き付けました。しかし、SquidはApacheにイメージを1回要求するだけでRAMからすべてを提供しましたが、Apacheだけで多数のワーカーをフォークしてイメージを提供する必要がありました。 Squidは、Apacheワーカーを解放して動的ページを処理するのにうまく機能するようです。
私の経験では、ワニスはイカよりもはるかに高速ですが、同様に重要なのは、イカよりブラックボックスがはるかに少ないことです。 Varnishを使用すると、問題のデバッグに役立つ非常に詳細なログにアクセスできます。また、設定言語は、Squidよりもはるかにシンプルで強力です。
@ Daniel、@ MKUltra、Cookieに関するVarnishの想定される問題について詳しく説明するために、実際には何もありません。それがcookieを返す場合にリクエストをキャッシュすることは完全に正常ですnot。 Cookieは主に、さまざまなユーザー設定を区別するために使用されることを意図しているため、これらをキャッシュしたいとは思いません（特に、セッションIDやパスワードなどの秘密情報が含まれている場合は！）。
サーバーが.jsと画像を含むCookieを送信する場合、それはVarnish側ではなくバックエンド側の問題です。 @Daniel（リンク提供）で参照されているように、Varnishに統合された本当にクールな言語/ DSLのおかげで、これらのファイルを強制的にキャッシュできます...
静止画像とその多くをプッシュする場合は、最初にいくつかの基本を確認することをお勧めします。
アプリケーションは、すべての正しいヘッダーが渡されていることを確認する必要があります（Cache-ControlやExpiresなど）。その結果、クライアントのブラウザがそれらの画像をローカルにキャッシュし、リクエスト数を削減するはずです。
CDNを使用します（予算内にある場合）。これにより、画像がクライアントに近くなり（通常）、クライアントのユーザーエクスペリエンスが向上します。 CDNを生産的な投資にするには、前の段落で説明したように、必要なすべてのキャッシュヘッダーが適切に設定されていることを確認する必要があります。
結局のところ、リバースプロキシを引き続き使用する場合は、varnishやsquidよりもnginxをプロキシモードで使用することをお勧めします。はいVarnishは高速で、nginxと同じくらい高速ですが、やりたいことは本当に非常に簡単です。複雑なキャッシングやESIを行う場合は、Varnishが独自のものになります。だから、シンプルに、愚かにしてください。 nginxは実際に非常にうまく機能します。
Tuxの経験がないので、申し訳ありませんがコメントできません。
それだけの価値があるので、私は最近、穏やかなDDoS攻撃（10Kリクエスト/秒）を受けていた6歳の低電力Webサーバー（Fedora Core 2を実行）のApacheの前にnginxをリバースプロキシとして設定しました。ページの読み込みは高速（100ミリ秒未満）であり、システムの負荷はCPU使用率が約20％と低く抑えられており、メモリの消費はほとんどありませんでした。攻撃は1週間続き、訪問者には悪影響はありませんでした。
毎分50万回以上のヒットが持続するのは悪くありません。必ず/ dev/nullにログインしてください。
興味深いのは、Apache Traffic Server（以前のYahoo! Traffic Server）について誰も触れなかったことです http://trafficserver.Apache.org/
それを見てください、それは美しく動作します。
http://www.mangahigh.com でワニスを使用しており、約100の同時プレワニスから560を超える同時ポストワニスにスケールできました（この時点でサーバーの負荷は0のままでしたが、だから、成長するための十分なスペースがあります！）ワニスのドキュメントの方が良いかもしれませんが、慣れれば非常に柔軟性があります。
VarnishはSquidよりもはるかに高速であることを意味します（Squidを使用したことがないので、確かには言えません）-および http://users.linpro.no/ingvar/varnish/stats-2009-05- 19 は、Twitter、Wikia、Hulu、perezhilton.com、および他の多くの有名人も使用しています。
私はイカしか使っていないので比較できません。イカを使用して、サイト全体を米国のサーバーにキャッシュします（すべてのデータはドイツのマシンから取得されます）。設定はとても簡単で、うまく動作しました。あなたがすでに何を探すべきかを知らない限り、私はドキュメントが少し不足していることがわかりました。
squidとnginxの両方がこのために特別に設計されています。 nginxはサーバーファームの構成が特に簡単で、FastCGIのフロントエンドにもなります。
静的および動的コンテンツを提供するApacheがすでにあるので、Varnishを使用することをお勧めします。
このようにして、Apacheを使用して静的コンテンツを配信し、ワニスを使用してそれをキャッシュすることができます。 Varnishは非常に柔軟性があり、ウェブサイトを最適な方法で成長させるためのキャッシュ機能とロードバランシング機能の両方を提供します。
Squidが HTTP仕様 に準拠している（または少なくとも彼らが試みている）ことについて誰も言及していませんが、Varnishはそうではありません。私の意見では、これはVarnishが個々のサイトのコンテンツのキャッシュに（Varnishを大幅に調整することにより）より適切であり、Squidが多くのサイトのコンテンツのキャッシュに適していることを意味します（各サイトは 仕様に従ってコンテンツを「キャッシュ可能」にする必要があります） ）。
IIS 6インストールの前にワニス2.01サーバーをロールアウトします。これまでに得られた唯一の注意点は、SSLに関するものでした（ワニスはSSLを処理できないため）。これらのリクエストを処理するためにNginxもインストールしました。
すべてのテストで、サイトが処理できるトラフィック量が66％増加していることがわかりました。
私の唯一の不満は、ワニスがCookieをうまく処理できず、ドキュメントがまだ少し散在していることです。