読者です 読者をやめる 読者になる 読者になる

squid vs apache

http://blog.livedoor.jp/nipotan/archives/50538571.html

を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど,
当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある.


その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった.
それはこんな理由による.

1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄

squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く.
よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい
ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった.
実際某サイトでは数十万URL程度で全く機能しなくなった.


その一方apacheはインデックスデータを持たない代わりに

  • URLからファイルの格納場所をその場で計算
  • キャッシュファイルのメタ情報は格納ファイルの先頭に埋め込んであってそこを参照


という機構になっていて,キャッシュするファイル数が増えても参照されない限りは
メモリが消費されないというアーキテクチャになっている.

2. apacheと違ってsquidは単一プロセスでアクセスをさばいている.

squidは何らかの理由でダウンしてリスタートするときにキャッシュインデックスを
ログファイルから読み直して再構築する.その関係上全部のログファイルを読み終わるまで
サービスが開始できない.何10万個もファイルがあると立ち上げに結構かかるためこれは
ちょっと痛すぎる.

3.単一プロセスで動かしているとメモリリークの影響がやはり怖い

仮にsquidがパーフェクトなプログラムだったとしても,使用しているライブラリまで
パーフェクトとは限らない.よって単一プロセスで動かしているという時点でメモリ
リークの影響は考慮せざるを得ない.なおapacheの場合MaxRequestsPerChildで子プロセスが
定期的に死んでくれてプロセスが消費したメモリは適当にリフレッシュされる).


4. apacheの各種モジュールが使えないのはやっぱし不便

apache便利すぎ.あとドキュメントがそろっててモジュールを作りやすかったのも大きい.


上記のことは3年ほど前に調べた話なので,もしかしたら今は状況が変わっているかも知れない.
違っているようだったらツッコミいただければ幸いである.
(おしまい)

追記

squid2.6ではCOSSという仕組みがあるので,事情がかなり違います.
こちらもあわせてどうぞ.
squid2.6のCOSSの話