アカウント名:
パスワード:
RFC 2616 HTTP/1.1 の 13 Caching in HTTP ではかなり詳細な制御が入っていますが、その辺りを見た上で言っていますか? 現実的には、大抵の Web アプリケーション側で適切なキャッシュコントロール用の情報を出力していないことこそが問題だと思いますが。
Web アプリでこの辺りを意識してきっちり作られているものは極めて少数ですから。
適当に書いたものなんて、Last-Modified も出さないし当然 If-Modified-Since も送られてこないし、その結果毎回全解釈して結果を出している、なんていうサーバに負荷をかけるだけかける物も少なくありません。
動的にコンテンツを生成するものでも、この辺りの制御が入っていればサーバ負荷をかなり減らすことはできるのですけどねぇ……。
サイトミラーリングツールなんかで、2 回目の取得でこの辺りを気にしないものも少なくないようにも思いますが。その手のクライアント側アプリケーションも、サーバ負荷を増やす原因になっていますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
Proxy 経由の場合 (スコア:2, 参考になる)
これは流石に厳しいので窓の手で普通に弄っていました。サーバに負荷が掛かるのは漠然と理解していましたけど。
挙動としては正しいような気もするのですが、実際に使うとストレスたまりました……タブブラウザが標準だし。
サーバ側の自衛策としては limitipconn とかで 2本以上は 503 ってのが妥当っぽい。
503 とか返されたときに忠犬のように待つ UA はあるのかなぁ……
# 逆に GetHTML は自主規制で 1接続を初期設定にしていますね。
Re:Proxy 経由の場合 (スコア:1, 参考になる)
授業中はほぼ常に503とかになりかねません。たぶん企業からのアクセスもしかり。
Web屋さんとしてはしっかりセッション単位で制限かけるべきでしょうね。
Re:Proxy 経由の場合 (スコア:2, 興味深い)
大学の英語の講義で、複数のクラスが一気に外部の個人が作ってる英語サイトにアクセスして、相手方サーバが落ちてしまい、結果まったく授業にならなかったのを見たことがあります。
# さらに先生も学生も情報リテラシーのない人間ばかり、リロードを繰り返す訳で...
Re:Proxy 経由の場合 (スコア:1, 興味深い)
ほとんどキャッシュされていない。若しくはヘッダにキャッシュ禁止とか書いてあるとみた。
ていうかほんとキャッシュProxyのキャッシュHIT率って年々下がってるんじゃない？
httpか何かの規格として、もっと詳細なキャッシュ制御や動的なキャッシュ制御を盛り込んではどうかな
Re:Proxy 経由の場合 (スコア:1, 参考になる)
それほど悪くはないです。現在でもアイコンとかの小さな画像部品は非常に効率よくキャッシュされます。
リクエストの絶対数が減らせるので、わりと効果あります。
Re:Proxy 経由の場合 (スコア:1)
RFC 2616 HTTP/1.1 の 13 Caching in HTTP ではかなり詳細な制御が入っていますが、その辺りを見た上で言っていますか? 現実的には、大抵の Web アプリケーション側で適切なキャッシュコントロール用の情報を出力していないことこそが問題だと思いますが。
Web アプリでこの辺りを意識してきっちり作られているものは極めて少数ですから。
適当に書いたものなんて、Last-Modified も出さないし当然 If-Modified-Since も送られてこないし、その結果毎回全解釈して結果を出している、なんていうサーバに負荷をかけるだけかける物も少なくありません。
動的にコンテンツを生成するものでも、この辺りの制御が入っていればサーバ負荷をかなり減らすことはできるのですけどねぇ……。
サイトミラーリングツールなんかで、2 回目の取得でこの辺りを気にしないものも少なくないようにも思いますが。その手のクライアント側アプリケーションも、サーバ負荷を増やす原因になっていますね。
Re:Proxy 経由の場合 (スコア:0)