PC関係のメモ
Pound を選択した理由 / Apache のパフォーマンス・チューニング / MRTG で Apache を監視するスクリプト
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 (リクエスト/秒)
おりゃーー。明日負荷かけるゾ！負荷！ｗ
forkしてソケットを大量に吐き出すスクリプト作成中！<br>コミュファ経由で発信します（藁<br>どうでもいいけど、トッツァンのメビウスにfedora coreインスコしようとしたらカーネルパニックしました・・
負荷（ ´∀｀ ）bどんと来い!!
トッツァンは頭皮がパニックっています。アヒャヒャヒャ(゜∀゜≡゜∀゜)ヒャヒャヒャ
漏れは二日酔いで Core を吐きそうです( -д-)