Pound を選択した理由 / Apache のパフォーマンス・チューニング / MRTG で Apache を監視するスクリプト
投稿日: 2003年12月04日 更新日: 2017年07月22日
Pound を選択した理由
<20031202#c04> でツッコミをいただいたので自分でもあやふやだった部分を整理。
キャッシュサーバ(Squid)を利用しないのはなぜか
結論から言うと今回のケースではキャッシュサーバの利用は難しい。
その決定的な理由は100%動的ページだから。キャッシュが効く静的コンテンツは画像しかない。
検討段階では「動的といってもリアルタイムに更新してるわけではないから大丈夫」と思ってたけど、
ひとつのページが
- 認証ユーザ
- REMOTE_IP
- COOKIEの値
- セッション
によって違う内容を出力する場合(プッシュ型コンテンツ？)、キャッシュはそれぞれの条件について必要になる。
また、同じユーザでも何かアクションを起こすたびにページが変化する可能性がある。(Amazonのオススメ商品みたいに)
あとは
アクセス数 アクセスはキャッシュサーバまでで、Webサーバにはアクセス記録が残らない。ではキャッシュサーバのログを取ればよいかというと、キャッシュサーバにすらアクセスされずブラウザのキャッシュが使用されてしまう場合もある。設定しだいで解決できる可能性あり。
キャッシュとプロキシのセキュリティの確保
- フォームの確認ページや内部LANからのアクセスでのみ表示するページがキャッシュサーバに溜まってそれを他の人に見られたら？
- プロキシ経由で他のサーバにアタックされたら？(踏み台)
- その他もろもろを防御する必要あり。キャッシュだけでも大変、プロキシのセキュリティ確保はもっと大変。しかもクリティカル。
と、クリアしなければいけないハードルがいくつか。「短期間に実現可能で低リスクな解決策」という条件がなければ適用可能だけど、結局動的ページに対しては・・・？
Pound を一台のサーバで運用する意義は？
こっちがメインだったのにキャッシュで時間食ったのでまた明日書き直す
とりあえず http://pc.2ch.net/php/kako/998/998166103.html の 4 が(・∀・)イイコトイッタ!! 7 もイイ！
引用すると
動的コンテンツでも、遅いクライアントのために、重いhttpdで
だらだらとセッションを張りつづける必要も無い。
当然、クライエントの転送終了までセッションをキープしなきゃダメだし
クライエントの速度は色々だし、
でも 9 の言うように負荷は大幅には下がらない。むしろCPUが効率的に利用されて負荷自体は上がる？
そこでロードバランサが登場！！でもバランス取るサーバがいないから先にPoundだけ導入しておいていつでも振り分けれるようにしておこう。上記のメリットもあるし。というのが今回の導入目的。
Apache のパフォーマンス・チューニング
MRTG で Apache を監視するスクリプト
さし当たって必要なのは * Busy Servers(起動しているプロセス数？) * Requests per second (リクエスト/秒)
この記事へのコメント
※ このコメントは旧ブログシステム(tDiary)からの移行です。
Tomさんからのコメント(2003-12-04 18:18:03)
おりゃーー。明日負荷かけるゾ！負荷！ｗ
ichieさんからのコメント(2003-12-05 00:19:12)
forkしてソケットを大量に吐き出すスクリプト作成中！コミュファ経由で発信します（藁どうでもいいけど、トッツァンのメビウスにfedora coreインスコしようとしたらカーネルパニックしました・・
hajimeさんからのコメント(2003-12-05 09:52:36)
負荷（ ´∀｀ ）bどんと来い!!
Tomさんからのコメント(2003-12-05 10:14:02)
トッツァンは頭皮がパニックっています。アヒャヒャヒャ(゜∀゜≡゜∀゜)ヒャヒャヒャ
hajimeさんからのコメント(2003-12-05 10:43:25)
漏れは二日酔いで Core を吐きそうです( -д-)
名前：宮内 はじめ
Code for Nagoya名誉代表
E2D3名古屋支部長
プログラマーです。GISやデータビズが好きです。このサイトは宮内の個人的なメモです。