ワニスと他の逆プロキシ

私は、VarnishをすべてのWebトラフィックのキャッシングリバースプロキシとして展開している組織と協力しています。彼らのトラフィックは、顧客が生成した多くの動的なWebサイトであり、静的なアセットの通常のコレクションが脇にあります。

私はワニスを好きにしていますが（原則としてかなり良いアーキテクチャを持っていると思います）、それを管理し、問題が発生したときにトラブルシューティングするのに苦労していますので、それが本当に正しい選択かどうか疑問に思っています。私は過去に逆プロキシとしてsquidを使用しましたが、同じ種類の役割ではないため、比較のための明確な根拠がありません。

私の質問は、生産でワニスを展開したか、代替案に対して真剣に評価した人々を対象としています。それにとどまるか、切り替えるためのあなたのキーポイントは何でしたか、そしてあなたが何か他のものを使用した場合、何を使用することになりましたか？

まあ、私は主にパフォーマンス上の理由から、WebサーバーでVarnishを実行していますが、その負荷分散機能も便利です。

私の使用例は、DjangoベースのWebサイトの前でキャッシュすることであり、ページ読み込みのパフォーマンスには驚異的です。ほとんどのページをキャッシュから直接提供することができ、ほとんど問題なく大勢の訪問者を処理できます。

ワニスを選んだ理由は、主にパフォーマンス/スケーラビリティでした。主なポイント：

• Varnishは、Squidがディスクとメモリのキャッシュを別々に保持しようとする仮想メモリをカーネルが管理できるようにします。これにより、カーネルとSquidがディスクにページアウトするものについて少し混乱する可能性があります。
• Varnishは独自のドメイン固有の構成言語であるVCLを使用し、Cを介してマシンコードにコンパイルします。これは、構成に少し以上のロジック（条件付きヘッダーのストリッピングなど）がある場合、非常に現実的なパフォーマンス上の利点です。

私の経験では、ほとんどの場合、ワニスはSquidよりも少し優れたパフォーマンスを発揮し、トラフィックの急増に対してははるかに優れています。一方、Varnishを正しく構成するには、メーリングリストトロールが必要になります。これは、特定のユースケースのドキュメントがネット上を流れるので、それほど多くないためです。 Squidの場合–主にVarnishが比較的若いプロジェクトであることによる。

沼地の標準的なlinux / dellハードウェアでVarnish 1.xを安定させるために長い時間を費やしましたが、常に奇妙な方法でハングし、そのウォッチドッグはそれを再起動しました。それは他のどこにも永続化されていないハードウォンキャッシュを除いて、うまくいきました...

そうは言っても、あなたは本当に仕事に適したツールを使用していますか？リクエストの結果をキャッシュするリバースプロキシが必要な場合（高品質のキャッシュヘッダーを提供している場合）、ニスは良いオプションです。バージョン2.0でより安定することを願っています

ただし、* onRailsサイトを実行していて、複数のバックエンドサーバーで負荷分散を行う場合は、HAProxyまたはNginxが最適です。複雑なURLロジック（リダイレクト、古いURLを書き換えるための正規表現の一致など）が必要ない場合は、HAProxyが適切です。より高性能なものが必要な場合は、nginxを試してください。