アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
Operaでは、 (スコア:4, 参考になる)
最大総接続数20(標準)
となっている。
ちなみに、どちらも128まで増やせる。
＠9.10で調べてみた。
さすが世界最速Opera(?)
そういえば、昔のOpera(4くらいかな？)には、Webページの定期更新(nSec毎にGet requestする)があったなぁ。
友人のアクセスカウンタをぶん回した遠い思い出(笑
Squidプロキシとかどうでしょ？ (スコア:1)
#Operaユーザーならトピックアイコンが無いことに文句を言って下さいよ。
ということはおいておいて、
Casheに強いプロクシを通すことでコンテンツサーバーの負荷を減らそうな気がするんですが、どうでしょ？
実際のところhttp://www.cybersyndrome.net/ [cybersyndrome.net]とかのリスト眺めててもいまいちどのプロクシが信用できるのか分からないです。
こちらが送信したクエリまでキャッシュするような「悪意のあるプロクシ」って都市伝説ですか？
安心して利用できるプロクシリストみたいのがあれば
サイトごとに特定のプロクシを経由するようにお願いしてみるとか啓蒙のしようがあると思うんですがねぇ。
プロクシって2chで手の込んだ自演するためにしか使われていないイメージ。
Youthの半分はバファリンでできています。
Re:Squidプロキシとかどうでしょ？ (スコア:4, 参考になる)
cache できるような静的なコンテンツは、アクセスが集中しても全然問題にならないです。
しかし、最近は blog だの wiki だのといったほとんど静的なのに動的に生成してるコンテンツが流行ってるから困りもの…
画像投稿掲示板的なcgiシステムを動かしているのですが、
たま～に「ウェブ高速化ツール」らしきものから、複数のリンクをまとめてアクセスしてきたりしてひどいことになります。
一応、load average が 一定値を超えるとアクセスを拒否するようにしてるのですが、
load average が上がるのはアクセスが集中した後なので、ほとんど無力というか
ひどいときはload average が 50 を超えたりすることもたまに…
静的コンテンツの方は、少々アクセスが集中しても問題ないので、対応が難しいところです。
#というわけで、自前の日記に毛が生えたようなエセblogシステムでは、ほとんどのコンテンツは html に吐き出すようにしてます。
#リクエストの量に比べて、内容が更新される頻度はそれほど多くないのに、
#毎回リクエストに応じて生成するのがCPU資源が「もったいない」ので好きになれません。
#それが、Web2.0 いうものなのかもしれませんが…
Re:Squidプロキシとかどうでしょ？ (スコア:2)
HTTP接続数をどう設定しようと、読み込むのはブラウザのキャッシュに見当たらないファイルか、そろそろ更新されているかも知れないファイルだけですよね？
下の方でFireFox＋FasterFoxで先読みを有効にした場合はローラー作戦で潰される、という意見もありましたが、
FasterFoxもキャッシュサイズを拡張する設定が付いているのでそれほど迷惑ではないかと。
Operaでもドキュメントと画像に対して更新の確認を何時間ごとにチェックするか選べますし、キャッシュサイズも最大400MBまで拡張できます。
#デフォルトは療法5時間ですので画像だけ24時間に直してみたり、
#RSSのデフォルト3時間は絶対やりすぎだろう、と思い登録するたびに直したりしてますが。
しかし、ブラウザ終了時やシャットダウン時にキャッシュを消したいユーザーも沢山いるでしょうから根本的な解決策としては外部に複数のユーザーでキャッシュを共有することであると思われます。
動的コンテンツの中にstyle属性やjavascriptソースが埋まっているのは論外として、
CSSやJSは外部ファイル化して(X)HTML自体は小さなサイズを維持する前提では
・閲覧者が一定のプロクシを利用する（例えばプロバイダ提供で）
・管理者もプロクシを用意する、もしくは一定のプロクシを利用するようにお願いする
のどちらかで画像と静的コンテンツに対するリクエストはプロクシのキャッシュまでで止まることになるでしょう？
そうすると、たとえブラウザが複数リクエストを出していようとも、サーバーに届くリクエストは本当に動的なコンテンツのみに絞られるのでは？
Operaではずいぶん前からプロトコルごとにプロクシを設定できるんですが、使ってません。
プロクシサーバーのIPアドレスがコロコロ変わってしまっていちいち設定が必要なのも問題でしたし、
Mixiみたいに入り口だけhttpsで後はhttp、みたいなサイトだとうっかり余計なモノまで読み取られないか不安になります。
必要なのは、信用できて安定してるプロクシサーバーでは？
と、ここまで書いておいて正直自分が無知なだけだと思っているんですがね、
僕より無知な人は沢山いるでしょうから詳しい人に真っ当な補足をお願いしたいです。
Youthの半分はバファリンでできています。
Re:Squidプロキシとかどうでしょ？ (スコア:0)
ってのは広く知られている方式だと思います。私もそういうサーバを構築したことがあります。
そういうこと?
Re:Squidプロキシとかどうでしょ？ (スコア:1)
#リバースプロクシという語はググって自己解決しました。
自前サーバーならば金銭的にどうしようも無いかもしれませんが、
例えばレンタルサーバー利用でレンタルに際してそういうサービスが提供されている実例はあるのか？
#当たり前すぎて開示すべき情報ですらない可能性もありますね。
他方、別の解決策として一般ユーザーもプロクシを積極的に利用するようになれば良いような気がしたんですが、どうも気軽に利用できるほど認知はされていないようであると。
例えば大手の接続プロバイダが全トラフィックをキャッシュしてみたり、少なくとも自前のブログやいわゆるホームページサービスぐらいまではキャッシュしていれば少なくとも内部は快適ですし、外部からのアクセスに関しても耐性が上がるんじゃないかとか。
トピックで問題にされている事象は、インターネット接続≒光になりつつある現在でも上記のような工夫を（コンテンツ｜接続）プロバイダ側がしても防ぎきれないような悪影響なのかどうかが疑問なのです。
はたして古いRFCにデフォルトで違反しているブラウザや、設定を弄ってハッカー気取りのユーザーが責められるべき性質の問題なのでしょうかね？
Youthの半分はバファリンでできています。
Re:Squidプロキシとかどうでしょ？ (スコア:0)
1. サーバ側でのReverse Proxy等、負荷軽減対策のテクノロジは普及しているか
2. ユーザ側が、野良のHTTP Proxyを共有することでパフォーマンスが改善するのではないか
3. 大手ISPの自社運用blogサービス等はキャッシュするとパフォーマンスが改善するのではないか
4. ユーザ側の設定変更(TCP接続数増加)はそんなに責められる、悪いものか
それぞれについて、私見を述べます。
1. サーバ側でのReverse Proxy等、負荷軽減対策のテクノロジは普及しているか
サーバ側での負荷分散テクノロジは(Proxy方式も含めて)それなりに普及してます。
お金
Re:Squidプロキシとかどうでしょ？ (スコア:0)
ACからのコメントは通知されない設定にしていますので閲覧が遅れました。
非常に参考になる意見をどうもありがとうございます。
勉強になりました。
お礼のみなのでACで
Re:Squidプロキシとかどうでしょ？ (スコア:0)
Re:Squidプロキシとかどうでしょ？ (スコア:0)
有料/無料をふくめ殆どのBlogシステムはHTMLに吐き出す静的コンテンツなのです。
Re:Squidプロキシとかどうでしょ？ (スコア:0)
見かけ上htmlにみえるけど、内部的には動的生成、というのも多いです
Re:Squidプロキシとかどうでしょ？ (スコア:1)
結局情報が漏れてみなきゃわからない話ですね。
予防策としては、串リストとか称されるリストに載ってるような
どこの誰が管理してるのかも怪しいプロキシを使わない。
ということくらいしか挙げられないですよね。
プロバイダが用意してるものとか、自前で用意してるものくらいですかね。
まぁ、串リストなるものを使う人たちの目的は「匿名性」の確保なのだろうから、的外れなんでしょうけど。
所詮、ローカルネットワークの中に1台サーバマシンを用意してプロキシを設置すれば、
キャッシュ効果で高速化するかなぁとか、その程度にしか使えないのです。
高速化目当てなら、airproxyとかAirEdge向けのプロキシを動かしてみるというのも手でしょうね。
画像を圧縮してくれたりするので転送速度は格段に上がるでしょう(ただし不可逆なので荒くなる)。
Re:Squidプロキシとかどうでしょ？ (スコア:0)
たまたまリクエストがキャッシュにヒットすればまだいいけど、
キャッシュミスヒット時の遅さが致命的です。
HTTP Proxyがコンテンツを取得してこないといけないわけだから、
なんと2回もTCP 3-way Handshakeをする必要があるわけだからね。
TCPセッションを終端しない、透過型のHTTP Proxyであればまだいいのかもしれないけど
その場合はサーバがパケットをルーティング or スイッチングしつつ、動的にパケットを
解析しないといけないわけで、パフォーマンスがものすごく悪そう。
(専用ハードウェアがあればいいのかもしれませんが、そういうの存在するのかなぁ)
Re:Squidプロキシとかどうでしょ？ (スコア:1)
ついでに、
IEが次のファイルを読もうとするのは他のファイルを読み終わった後だから、窓を複数開いて、AサイトとBサイトを読んでいる時に偶然4つのセッションが全てAサイトを読んでいた場合で、Aサイト側の窓を閉じるとBサイト側は読み込み途中で止まってしまう。
Bサイト側を1個でも読んでいてくれれば、そのファイルを読み終わった段階で読み込みセッション数が戻るけど。
Re:Squidプロキシとかどうでしょ？ (スコア:0)
キャッシュというか、ロギングの事かな。
手元でOpen Proxy立ち上げて「串掲示板」みたいなサイトに
IPアドレスを書き込んでニヤニヤする、なんてのは
普通に誰でもやっていると思うけど……。