squid の効率をチェックして、キャッシュをクリアする。

SUSE 11 で Squid3 を導入、設定
の続き話です。

ユーザにとっては「ウェブアプリケーションが重い」と思うのは全てが「インフラの責任」と考えています。しかし、実際には、最高のインフラを与えても「重いものは重い」のです。多くはクライアント、ブラウザの性能と、通信遅延、相手のサーバーの負荷によるもののようです。

squid を使っていると時々トラフィックが上がり不安定な時があり、その場合は大抵 squid キャッシュを削除して、squid を再起動すると「治ってしまう」ようです。どうも、squid.conf で設定した閾値（threshold）付近で squid の動作が不安定になるようです。

となると、どのタイミングで「キャッシュをクリア」するかが問題となります。

-squidclient を使う-

squid:~ # squidclient -h localhost -p 8080 mgr:client_list
(-p は squid.conf で設定した値)

-cachemgr.cgi で調べる-

Cache Clients:
Address: 192.168.1.40
Currently established connections: 4
ICP Requests 0
HTTP Requests 3
TCP_MISS 3 100%

:
: 略
:

Address: 192.168.1.55
Currently established connections: 2
ICP Requests 0
HTTP Requests 31130
NONE 17 0%
TCP_HIT 1409 5%
TCP_MISS 15538 50%
TCP_REFRESH_UNMODIFI 2859 9%
TCP_REFRESH_MODIFIED 188 1%
TCP_CLIENT_REFRESH_M 2 0%
TCP_IMS_HIT 2764 9%
TCP_MEM_HIT 4236 14%
TCP_DENIED 4117 13%

Address: 192.168.1.28
Currently established connections: 0
ICP Requests 0
HTTP Requests 5
TCP_MISS 5 100%

TOTALS
ICP : 0 Queries, 0 Hits ( 0%)
HTTP: 50620 Requests, 14024 Hits ( 28%) <-- ここ注目

-ログから調べる-

access.log の MISS 行と HIT 行をカウントします。

squid:~ # cat /var/log/squid/access.log | grep MISS | wc -l
17843 <- ミスヒットしたアクセス数
squid:~ # cat /var/log/squid/access.log | grep HIT | wc -l
7539 <- ヒットしたアクセス数
squid:~ #


ただし、これではあくまでも「ヒット数」であり「実際のトラフィック」ではありません。

PR

-キャッシュヒット数ではなく容量を-

そこで、実際にどれくらいの「量」がキャッシュされているのかを考えなければなりません。
du コマンドでキャッシュの「量」を測ってみます。

squid:~ # du -h /var/cache/squid/
4.0K /var/cache/squid/0B/E8
4.0K /var/cache/squid/0B/21

:
: 略
:

323M /var/cache/squid/
squid:~ #

今のところ 300M 程度のキャッシュが使われています。

-そのキャッシュは使われているの？-

squid:~ # ls /var/cache/squid -lR

実際に使われているキャッシュの日付があります。

/var/cache/squid/0E:
total 1024
drwxr-x--- 2 squid nogroup 4096 Nov 7 08:31 00
drwxr-x--- 2 squid nogroup 4096 Nov 7 08:31 01
drwxr-x--- 2 squid nogroup 4096 Nov 7 08:31 02

: 略


空のキャッシュもあります。
/var/cache/squid/0E/00:
total 0

/var/cache/squid/0F/FF:
total 0


-一日でキャッシュはどれだけ育つか-

squid:~ # /etc/init.d/squid stop
Shutting down WWW-proxy squid - wait a minute or two... .............done
squid:~ #

この間に squid のキャッシュを削除します。

squid:~ # rm /var/cache/squid/* -rf

squid を起動します。

squid:~ # /etc/init.d/squid start
Starting WWW-proxy squid done
squid:~ #

この状態から

squid:~ # du -h /var/cache/squid/

を実行して "xxxM /var/cache/squid/" の行を「毎日」チェックすると、「一日どれだけキャッシュが育つか」がわかるわけです。

-リアルタイムに iftop で状況を調べる-
コンソールで iftop コマンドを実行すると今の TX(送信)と RX(受信)状態がリアルタイムに監視できます。


ただし、このコマンドをリモート端末から実行すると、アップデートのパケットも含まれてしまうため、あまり信頼性があるとは思えません。gnome の場合 gnome-system-monitor があるのでこりゃ便利と思って使ってみたら、半分の TX パケットはリモート端末からのものでした。

まぁ「ちょっとだけ見てみたい」場合には有効なツールだと思います。

-snmp 監視ツール-
mrtg や zabbix のような snmp を使った監視ツールは、比較的少ないクエリで、通信量をグラフ化してくれます。


--
さまざまなツールでいったいどれくらいの「量」のデータが squid キャッシュを通り抜けているのかをいろいろ調べてみると、やっぱり３割から４割程度の通信が squid 経由で提供されているというのがなんとなくわかりました。だからと言ってブラウザ全体のパフォーマンスが異常によくなったということはあまりありません。

しかしPDFなどのドキュメント類は「爆速」です。
もし、PDF や画像を多用する事業所のネットワークであれば、ヒット率、よりも「ヒット量」に貢献する可能性は高いと思います。

実際に「何となく」調べてみると、ウチの様な零細事業所では週に１Gバイト以上、１日数百Ｍバイト程度「キャッシュが育つ」ことが解りました。これが多いか少ないかは微妙なところですが、明らかにある面ではブラウザの体感速度が上がるケースもあるわけです。この「キャッシュが育つ量」を使うブラウザの数で割ってみれば、大体ブラウザ一つでどれくらい効果があるのかわかるでしょう。ウチの場合、主に２台のＰＣを使っているわけですが、これが１００台１０００台となるとキャッシュ効果は結構なものとなるわけです。

実際、色々とLinux の ISO ファイルのダウンロードだとかをしているわけですが、巨大なファイルはキャッシュしても意味がありませんし、ブラウザ経由でsquidが「仕事」をしているのはこの程度なのですね。

--
最近はブラウザのバージョンアップが頻繁で、ＩＥの古いバージョン（６はもちろん７，８，９までも）が対応していないため、仕方がないので他のブラウザも併用するケースもあります。となると結構な効果があります。社内業務はＩＥ８で、GoogleApps は Chrome でといったケースですね。こうなると、エンドユーザは「好きなブラウザ」を使うしか方法はなくなります。もっとも Chrome はシステムの設定を使うことになるので Group Policy で制御できます。

また ls -lR コマンドでキャッシュの日付を見ると古いものも結構あります。古くても更新されていないコンテンツであれば、キャッシュを返してくれるわけですから、一概に「古いキャッシュはいらない」というのはちょっと無理ですが、実際、どれくらい「役に立つか」は納屋に繋がれた老馬の価値とか、昨日鶏が生んだ卵の新鮮さを判断するようなものです。

ここで重要になってくるのは「どのタイミングで古い」と判断するかでしょう。

業務によっては「昨日のキャッシュでも古い」ところもあれば、「一週間前のキャッシュでも」ありがたいところもあるということです。この判断は難しいところですね。

ただし du -h コマンドで測定した「キャッシュ量」と ls -lR コマンドでみたら、指定したキャッシュサイズに達したのに「キャッシュがないフォルダがある」ところが微妙です。

ということで、閾値に達するまでひと月、私の環境では月に一度、squid キャッシュをクリアして、squid を再起動するのがちょうど良さそうです。もう少し利用料が多くなれば、 squid キャッシュのクリアの間隔は短めにするか、 squid の閾値を上げるのがよさそうです。


-クラウド時代のキャッシュ-

さて、いろいろ見てきたところ

- Update 系のキャッシュはほとんど役に立たない。
- ストリーミング系はキャッシュされない。

また残念なことに

- アプリストア系のキャッシュはあり得ない。

ということがわかってきました。やれ「ブラウザでアプリケーションが使える」と言った Web App 系はほとんどキャッシュ効果はありません。

逆にタブレット系のアプリキャッシュもほとんど squid キャッシュでは効果がないと言えます。(ちゃんとマニュアルに書いてあるじゃん！)

第30章 Squidプロキシサーバ

https://www.suse.com/ja-jp/documentation/sles11/singlehtml/book_sle_admin/cha.squid.html

また、FTP、Gopher、SSL、およびWAISの各プロトコルをサポートしていますが、Real Audio、news、またはビデオ会議など、他のインターネットプロトコルはサポートしていません。Squidは様々なキャッシュ間に通信を提供するUDPプロトコルのみをサポートしているため、他の多くのマルチメディアプログラムはサポートされません。

私は開発者ではありませんが、インフラ系の技術者として、開発者に「文句」を言うなら、「クラウドのキャッシュ」も考えて開発してほしいということです。勿論、アクセス数だとか利用者数なんかをリアルタイムに見たいという欲望はあるので、それは理解します。しかし余りにも開発者がインフラの容量を「無限大」に考えていることは問題だと指摘してみたいですね。私も開発者でしたから、「UNIX ではメモリは無限大につかっていい」と言われてマイコン向けプログラミングのケチケチしたメモリの使い方はいったん忘れたことがあります。

現実に、今まで５分かかっていたダウンロードがウェブキャッシュのおかげで３０秒に短縮されたとしても、ユーザにとっては「待てない時間」であることは変わりありません。

先日 Windows 8 を 8.1 にアップデートしましたが、これは「最悪なクラウドアプリケーションのダウンロード方法」だと思います。この中にインフラ系技術者が入り込む工夫の余地はありません。

ブラウザで何でもできる、という幻想は既に時代遅れ。Evernote だとか SkyDrive だとかのクラウドサービスが出てくると、ブラウザ一辺倒ではなくなります。

クラウド時代のキャッシュサービスの考え方も見直さないといけないのでしょうね。

Webフロントエンド ハイパフォーマンス チューニング

お問い合わせはこちら
islandcenter.jp