kazekiriによる
2006年12月20日 18時13分の掲載
そいや4ってどこからきたのだろう部門より
そいや4ってどこからきたのだろう部門より
Anonymous Coward 曰く、
Web屋のネタ帳に百式の中の人、RFC違反はもちろんWebサーバ運営者の迷惑をまるで考えない設定を 推奨するの巻というエントリがある。百式の姉妹サイトであるpop*popにてFirefoxとIEを高速化するための動画チュートリアルという記事があったのだが、ようはこの記事ではFirefoxとIE(Windowsのレジストリ)の設定を変えて、HTTPの同時接続数を10にまで上げてしまうということを推奨していたため、それに対して反対意見を述べているのである。
HTTPの同時接続数はHTTP 1.0では特に制限はないが、通常どのブラウザも4までにしている。 HTTP 1.1では2を上限とすることが推奨されている。TCPコネクションの数を増やせば、まあ ユーザからは一見快適になるかもしれないが、それが常態化すればサーバ側からすればたまったものではないことは確か。その意を汲んでpop*popのほうでは、記事が訂正されている。
ただ、記憶を遡れば、Netscapeが4本もコネクションを張る!と激怒していた頃はもはや前世紀なのだなぁと思い出すと、RFCによる同時接続数の コンセンサスも現在では古い感覚なのだろうか? まあ、けど10本も接続されたら、DoSアタックだと見なされるところも多いと思いますが。
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
利己的に増やさない (スコア:5, すばらしい洞察)
自分一人だけ割り込みできたら早くなりますが、皆が割り込みするようになったら、混雑してむしろ遅くなります。海外旅行等で経験した人もいると思います。
なんか囚人のジレンマに似てますね。
また、サイトによってはサーバ側で同時接続数を制限していることがあります。
IEやFirefoxの実装は知りませんが、昔ダウンロードソフトの類を使ったとき、（制限で）接続失敗してるのに何度も接続しようとしてかえって遅くなってました。
ダウンロードが主のサイトでは制限していることが多いので、どうでもいいサイトで若干速くなっても、いざ大きいファイルをダウンロードするときに遅くなったのではむしろ損です。
以上の理由から、サーバ運営者の迷惑をまるで考えないで利己的に考えても増やさないほうが良いと思います。
Re:利己的に増やさない (スコア:2, 参考になる)
当時サーバ管理者としてデビューして一年ちょっとでしたが、Apacheのプロセスが大量に出来てしまい管理のためにリモートログインすらままならず、吃驚したことがあります。
# 対策として(FreeBSD4.X系でしたので)maxusersを増やしてカーネル再コンパイルをして、ApacheのmoduleによりIPアドレス1個に対して1コネクションしかはれないように設定しました。
対策後、順調に収まっていったんですがmoduleがCPUをコネクション接続瞬間毎に喰う現象が見られ結局対策を見いだせないままマシンパワーを挙げるという力業でしのいだことがあります。
私としては、接続コネクションを増やした分早く転送が終われば基本的には良いと思います。ですが、遅い回線からのアクセスは困りますね。
転送速度が遅くてプロセスを解放してくれるまでに時間がかかるのは、サーバ管理者サイドからすると余り好ましくない人だと思います。
かといって、無下にコネクションをぶちっと一定速度以下は切断するようなこともできないわけですし…。
10コネクションはろうともそれが1頁あたり0.5秒以下で全転送が転送が終わるのではれば複数同時コネクションありかなと思います。
正し、最近多いメニューなどのデザイン性を高めるために画像を細切れにしてきれいに表示しようとしているサイトを抱えているサーバにとっては、
サーバへのアクセス数を更に増やすことになるので、個人的にはそっちからも何らかの対策を考えて欲しい所です。
クライアントの設定も悪いけど、無駄に画像を配置しまくってかっこよくなったと満足している作成者側にも見直して欲しい所です。
# Web2.0全盛になると更にサーバへの負担がより増える気が…。
親コメント
SHOULD NOT (スコア:5, 参考になる)
個人的にこの手の文書における should はかなり強い意味だと思っているので、「構わない」という訳には抵抗があります。「有用な場合もあるかもしれないが、全ての意味が理解され、また慎重に判断されない限り、この語の用いられている機能の一部でも実装してはならない」くらいかな。
# "You shall die!" → 「殺してやる！」みたいな :-)
プラスモデお願いします。 (スコア:2, 参考になる)
"SHOULD NOT"は、限りなく"MUST NOT"です。
"MUST NOT"があまりの強意であるが故、
修辞上の表現として"SHOULD NOT"にて代替されているのが真意です
親コメント
Re:プラスモデお願いします。 (スコア:2, おもしろおかしい)
親コメント
Operaでは、 (スコア:4, 参考になる)
最大総接続数20(標準)
となっている。
ちなみに、どちらも128まで増やせる。
＠9.10で調べてみた。
さすが世界最速Opera(?)
そういえば、昔のOpera(4くらいかな？)には、Webページの定期更新(nSec毎にGet requestする)があったなぁ。
友人のアクセスカウンタをぶん回した遠い思い出(笑
Re:IE (スコア:2, 参考になる)
> というスパマーや、チェーンメール送信者と同じモラルレベル、
> と受け取られても、文句は言えないんじゃないですかね？
何言っても減ることはないので、最近は
フィルタで対応できるから、勝手にどうぞ。というスタンスになってきました。
携帯の場合だとフィルタが細かく指定できないので、
スパム業者じゃなくて、携帯業者にもっとフィルタ機能充実させろって言ってますし。
結局、ユーザーの不満はサービスを提供する側に集中するんです。
法定速度は50km/hだけど、この道の流れは70km/hが基本。
だけど、法定速度は守りましょうね。という感じの話かと思います。
# こちらは法的に取り締まられますが。もちろん法定速度は厳守でお願いします。
親コメント
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の半分はバファリンでできています。
親コメント
議論の対象となるべきなのは (スコア:3, すばらしい洞察)
(RFCに従う必要があるかどうかは別問題ね)
普通の人はRFCなんて知らないし、知ってる必要も無いでしょ。
そういう普通の人が「同時接続数増やしたら速くなるんだぜ」と自慢しても、それは責めたりするべきではないと思う。普通の人なんだから、設定弄るだけで速くなるんだったらやっちゃうよね。
多くなってもよいのでは (スコア:3, すばらしい洞察)
HTTP/1.1（RFC2080やRFC2616）が発行されたのはブロードバンドには程遠い時代のことです。
その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
よほどの大人気サイトでなければ致命的に高負荷になることもないでしょう。大人気サイトであればロードバランサやクラスタリングなどでいくらでも回避の手を打つことが可能です。
巨大なトラフィックが発生する動画ストリーミングなどはクライアント・サーバ型ではなくP2P等の技術で実現されたり、何百台も使ったクラスタリングをする方向にあってサーバサービスの分散強化傾向がどんどん強まっています。
いわゆるWEB2.0？以降の現代はサーバ側のサービス供給力を競う時代でもあり、クライアントはAdSenseを見てくれたり商品を購入するお客様という考え方のもとに勢いよく進化しています。
したがって今やクライアントに対する規制を論ずるのは進化に対して逆方向だと思うのです。
クライアントがサーバに高性能を求め、それに応えられるサーバが勝ち組として生き残れる、そんな競争原理が進化の原動力なのではないでしょうか。
Re:多くなってもよいのでは (スコア:4, 参考になる)
同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを送ることで、結果的に無通信時間が減り、全体のスループットが向上する。
それなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。
それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。
HTTP/1.1 ではサーバ側でパイプラインに対応することが必須だから、HTTP/1.1 なら、同時接続数は少なくても(基本的に)問題ありません。
以上、ページ表示に必要なデータがすべて揃うまでの時間を考えた「スループット」についての考察です。
ロード途中でもページを表示できるようなブラウザだと、その途中での「レイテンシ」については同時接続できた方がうれしい場合が多そうです。
大きな html と(html中で指定された)小さな css を読むときに、html が全部届いてから css を受け取るよりは、同時接続とかで先にcssを貰った方がありがたそうだし。
親コメント
Re:多くなってもよいのでは (スコア:2, すばらしい洞察)
>「リクエスト?結果受け取り?リクエスト?結果受け取り」を繰り返してたら、待ち時間が
>あるために通信利用率が減って全体でのスループットが落ちるから。
誤解を招く、というか説明が少し足りないようですね。
「待ち時間」がどのような待ち時間なのかが問題です。
毎回接続・切断するのはHTTP/1.0までの話で、現在主流のHTTP/1.1ではKeepAliveに
よって接続を維持したまま複数のデータの取得が出来ますね。
同時セッション数を増やすことでスループットが上がるのは、アプリケーション層の
HTTPのレベルよりも、むしろトランスポート層のTCP/IPレベルですね。
TCP/IPではラウンドトリップタイム(RTT)によって実際の帯域以下にスループットが
下がってしまいます。
「送信して受信確認が来たら次の送信」というようにするので、受信確認のための
待ち時間が大きく響くのです。RTTが大きくなると極端に低下します。
関東に住んでいる人たちは大抵のサーバに距離的に近いため意識する機会が少なく、
忘れがちな話ですが、地方に行くと結構問題になります。
>同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを
>送ることで、結果的に無通信時間が減り、全体のスループットが向上する。
無通信時間が減ってスループットが上がるというより、使用できる帯域は単純に
２倍になります。もちろん使用回線の帯域が上限となりますが。
大きなRTTによるスループットの低下では、100Mbpsの帯域があっても20Mbpsほどしか
使えないケースもあります。その場合に２セッション同時に通信すれば、40Mbpsくらい
使えるようになります。
この場合サーバ側で問題となるのは、遅いコネクションを多数張られるようになることです。
サーバとしてはさっさと通信を終えて他のコネクションの相手をしたいのに、遅い接続が
大量に滞留すると同時セッションが限界に達してしまい、新たに接続しようとしても
待たされることになってしまいます。
かつて、たった9600bpsしかないi-modeの通信が急増したとき、サーバ管理者、特に
バーチャルホストサーバの管理者は戦々恐々でした。
i-modeコンテンツがあると、遅いi-mode向け通信だけでHTTPのセッション全てが埋まり、
他のPC向けの通信がほとんどできなくなる現象が多発したからです。
これは「大容量の帯域」であっても関係なく発生しました。
現在ではドコモ側もPROXYを改良して対処したようですが。
３車線の高速道路があって、３車線とも併走すれば通行できる車両数は３倍です。
でも、やはり出せる速度に応じて速い車両は右側を走るように分けたほうが
流れは良くなりますよね。
たまに遅い車が３車線ともいて、同じ速度で走っているために渋滞を引き起こす
ことがありますよね。
スーパーのレジでも「大量に買う人（カート）専用」「少量買う人（カゴ）専用」と
分けられているところがありますね。
短時間で処理できる客は短時間で通過させたほうが効率が良いのです。
だから結論としては、「同時セッションを多くしてもいいけど、限度はある。
やりすぎないようにほどほどに」といいたいです。
現実的には、IE, Firefoxの規定値のままが「ほどほど」だと思います。
親コメント
Re:多くなってもよいのでは (スコア:3, 参考になる)
RFC2616 の制限はサーバひとつについて同時2接続まで、といってるだけで、
リソースがふたつのサーバにわけて置かれているのならば 2 x 2 で同時4接続しても
まったく問題なく、あなたの挙げる前者の例は的外れです。
さらに、1サーバであっても、複数接続が最大2とはいえ禁止されているわけではないので、
>何らかの理由でa.jpgが返ってこなければ後続の b.jpgやc.jpg
はもうひとつの接続のほうが生きていればちゃんと取得できます。
>最近のブラウザはパイプライン機能を持っていますがたとえば firefox2.0等でもデフォルトではこの機能はOFFになっているぐらい
persistent connection と pipelining を混同してませんか。
前者は1回の接続で複数のリクエスト/レスポンスのやりとりをおこなうこと、
後者はレスポンスが完了しないうちに非同期に次のリクエストを出すこと。
pipelining が firefox でデフォルト off なのは事実ですが、今話題になっている件とは関係なく、
persistent connection は firefox でもデフォルト on です。
親コメント
Re:多くなってもよいのでは (スコア:2, 興味深い)
ダイヤルアップが当たり前・せいぜいがISDNの128kbpsだった時代には、末端のユーザが最大速度でアクセスしてもその負荷はたかがしれていました。
…が、その感覚で、1Mbpsは普通に出るADSLや実行でも数十Mbps出る光回線からアクセスされるとたまったものではありません。
GetHTMLWの旧バージョンが、数アクセス/秒の頻度で根こそぎダウンロードしていたログに出くわして、しみじみそう思いました。昔なら、同時接続数4・ノーウェイトでもたいした問題はなかったのですけどね。
なお、現行バージョンのでは
となっています。
＞大人気サイトであればロードバランサやクラスタリングなどでいくらでも回避の手を打つことが可能です。
普段から負荷がかかるサイトならばともかく、突如負荷がかかる場合があります。
たとえば、/.Jのコメントからリンクを張るだけでもだいたい1アクセス/分ぐらいです。タレコミ本文からだったら、桁が変わるでしょう。「カトゆー家断絶」からのリンクの場合、ピーク時に2アクセス/分ぐらいでした。おそらく、ページの内容と読者層が重ならなかったためにこの程度のアクセスで済んだと思われますが、場合によっては桁が2つほど変わることも十分あり得るでしょう。
＞クライアントがサーバに高性能を求め、それに応えられるサーバが勝ち組として生き残れる、そんな競争原理が進化の原動力なのではないでしょうか。
ADSL回線にぶら下がったPen3/600MHzのうちのWebサーバなんぞは最底辺でしょうが、そこまで酷くなくても、高速回線にぶら下がった高性能マシンだけがWebサーバでは無いと思うのです。
とはいえ、#1079136 [slashdot.jp]の
＞3本以上のコネクション張れないように！ → 技術的に解決可能
というのもごもっともで、これからはサーバ側が、高速回線当たり前の世の中に対応していくことが必要なのかもしれません。
親コメント
pipelining使えよ (スコア:3, 参考になる)
IEはpipeliningを実装してるのかどうかも調べてませんけど、Firefoxではデフォルトオフとはいえ実装されてます。
なのでこれをオンにするだけで相当速くなるんですよ、Firefox。
他のチューニングなんてオマケみたいなもん。
Operaはよくしらないけど、誰かが「デフォルト8になってるのはpipeliningの最大リクエスト数」って言ってました。
なのでうちのFirefoxもそれに合わせてmaxrequestsを8にしてあります。
まあ、あんまし最大接続数増やしていい気になってると、mod_limitipconnみたいなのでガンガン対策されて、NAPTの内側で見てる人が503食らいまくる世界になるわけです。
ホントに迷惑被るのはサーバ管理者じゃなくてこういう人たちね。
Re:pipelining使えよ (スコア:3, 参考になる)
persistent connection:
クラ: 接続したいよ。
サバ: OK。
クラ: ファイル1ちょうだい。
サバ: はいよ(ファイル1)。
クラ: ファイル2ちょうだい、終わったら閉じていいよ。
サバ: はいよ(ファイル2)。(コネクションを閉じる)
pipelining:
クラ: 接続したいよ。
サバ: OK。
クラ: ファイル1ちょうだい。ファイル2ちょうだい、終わったら閉じていいよ。
サバ: はいよ(ファイル1)。はいよ(ファイル2)。(コネクションを閉じる)
どちらもコネクションはいちいち閉じません。
そして、Firefoxはデフォルトでもちゃんとpersistent connectionを使います。
親コメント
そういう制限はクライアントにさせるよりも (スコア:2, すばらしい洞察)
# 5xx:500番台は一時的な失敗。
Re:そういう制限はクライアントにさせるよりも (スコア:2, おもしろおかしい)
402 Payment Required
親コメント
Re:そういう制限はクライアントにさせるよりも (スコア:2, 興味深い)
リバースプロキシなんかにセッション数に応じて5xxを返すようなものはあるんじゃなかろうか。
SMTPやP2Pなんかの特定の通信をパケットレベルで遅くするような機器もあるようだから、そういうのも使えるんじゃないかな。
親コメント
Proxy 経由の場合 (スコア:2, 参考になる)
これは流石に厳しいので窓の手で普通に弄っていました。サーバに負荷が掛かるのは漠然と理解していましたけど。
挙動としては正しいような気もするのですが、実際に使うとストレスたまりました……タブブラウザが標準だし。
サーバ側の自衛策としては limitipconn とかで 2本以上は 503 ってのが妥当っぽい。
503 とか返されたときに忠犬のように待つ UA はあるのかなぁ……
# 逆に GetHTML は自主規制で 1接続を初期設定にしていますね。
Re:Proxy 経由の場合 (スコア:2, 興味深い)
大学の英語の講義で、複数のクラスが一気に外部の個人が作ってる英語サイトにアクセスして、相手方サーバが落ちてしまい、結果まったく授業にならなかったのを見たことがあります。
# さらに先生も学生も情報リテラシーのない人間ばかり、リロードを繰り返す訳で...
親コメント
FasterFox (スコア:2, 参考になる)
ただこれ、RFC違反と明言しているターボ(サーバ当り24コネクション(persistent 8)・パイプライン最大8)はともかく「RFCに従った最適化」と言うモードでも結構無法な設定 [mozdev.org]になっている(サーバ当り16コネクション(persistent 6)・パイプライン最大6)ようで微妙な気がするんですが、どのRFCなんですかねこれ。私は「微調整」設定にしていますが、ページの読み込み時間が ms 単位で出るのが結構便利だったりします。
このアドオンでは Prefech するのも微妙だなと思ったんですが、Mozilla Link Prefetching [mozilla.org] にしたがっているようで link 要素のものを先読みしているらしいです。
それとは別に(最近の版の)標準では無効化されている「先読み」と言う設定はあって、こっち a 要素を絨毯爆撃してくる類のものです。正直言ってサーバの同時接続数も迷惑ですが、この手の「リンク先の絨毯先読みアクセス」ほど迷惑なものは無いですね。
生のWindows SP2では (スコア:2, 参考になる)
Patch当てれば [bitcomet.com]できるけど。
#FlashGet [flashget.com]とか天敵ですかね。
どうあるべきか？ (スコア:1, 興味深い)
Re:どうあるべきか？ (スコア:2, 参考になる)
ビジーなら皆で分け合おうよ、暇ならある程度多めに使ってもいいよ、的な動的な制御をサーバでさ。
TCP/IPあたりなどのスライディングウィンドウとは傾向が違うけど、リソースの動的な調整は
やろうと思えばできなくはないし、昔のリソースの少ない時代の静的な設定に固執することも
ないと思う。
ねぇ、IPアドレスの割り当てだって今じゃDHCPが当たり前の時代なんだしさ。
#問題は誰がそれに気付いて始めるかだけどね。
#ま、現状でも破綻してなきゃそのままでもいいのかもしれないが。
親コメント
Re:どうあるべきか？ (スコア:2, 参考になる)
たまに「お手製クローラー」で、10本も20本も接続してくるクライアントがあるので、同一IPの短時間の要求には、応答速度を絞ってしまいます。
加減が難しくって、やりすぎると通常のアクセスも絞ってしまうので、注意が必要ですが。
どんなコンテンツへのアクセスかとか、どの頻度が適切かなどを測定して、ちょうど良い設定に落ち着けるのは大変かも。
親コメント
不特定多数の利用者の振る舞いは予想しにくいので (スコア:1)
もうこれからはコンピューティング・ソサエティ・サイエンスという分野を設けてはどうだろうか。
例えば、P2Pアプリケーションと総トラフィック制御方法論、とか。
「風が吹けば桶屋が儲かる」
---
TaddyHatty - always @( posedge ↑ or negedge ↓ )
でもさ (スコア:1, 興味深い)
IE7 は 32 が省略値 ? (スコア:1, 興味深い)
クライアント側の同時接続数は10でも20でも構わんが。 (スコア:1)
# 肩甲骨を使って、お手手が4本にできる三つ目族の方はコメントをお控えください。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
4という数字 (スコア:1, おもしろおかしい)
当然、inewsが.newsrcを読む行数の制限からに決まってるじゃないですか(w
SMTPの場合 (スコア:1)
一方、qmail はそれができないので、DOSやスパマーのプロセス専有に
弱い面があります。
Apache の場合は、postfix でのクライアント毎の接続数制限である
「smtpd_client_connection_count_limit」に相当する設定ってある
のでしょうか？ それができると、サーバー側で対処できますね。
「MaxClients」は、Apacheプロセス全体における最大接続数の設定だ
から違いますし・・・。「MaxKeepAliveRequests」ですかね。
参考: smtpd_client_connection_count_limit [kobitosan.net]
攻防戦 (スコア:1)
見た目上、コネクションを増やすと高速化（されたように見える）ブラウザ。
コネクションが増えると同時負荷が増えるサーバ。
ブラウザやサーバ（の設定）が混在環境だからそれなりに機能していますが、もしブラウザとサーバが規格化されたのなら、田代砲等で何本（何コネクション／sec）の弾幕を張れば（サーバを）落とせる。というのも見破られてしまうのでは。
＃まあ。どっちみち・・・・常識外の数打たれたら、どうしようもないわけですが。
＃壮大なストーリ。空転するアイディア。
404 (スコア:3, おもしろおかしい)
親コメント
Re:ここは、関係者に (スコア:2, おもしろおかしい)
「ウチはほとんどテキスト」
図表など、画像を使わないことにはどうしようもないところだけ画像使用。
「詳細」「前ページ 1 2 3 ... 次ページ」ごときをグラフィカルなボタンにするなんてトンデモナイ。
背景画像？ な、な、な、なんて贅沢な。
なに、見栄えにもこだわりたい？ であれば…。
「つまらないコンテンツしか置かない」
これ最強。
親コメント
Re:技術的な根拠あるの？ (スコア:1)
＞問題ないんじゃないかなぁ～
10や20の画像が含まれてるページはあるんじゃないですかね？
# サーバの性能如何では、むしろ接続(転送の)持続時間を短くできて
# そんなに負荷をあげずに快適度を上げれることも
# あるんじゃないかなぁとは思うの
親コメント
Re:ここは、関係者に (スコア:1, 興味深い)
RFC通りに解釈してください。
あまりにひどかったら弾くけどね。テヘッ☆
shouldじゃなくてSHOULDな理由が分からない人はこれを読もう
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels [ietf.org]
RFC原理主義者ならば、もちろんこれにも従うよね？
親コメント
Re:ここは、関係者に (スコア:1, 興味深い)
職業としての管理者、それだけでなく、サイトそのものを公開することを決定し、管理者に対価を払っている団体、個人は、閲覧者がいてくれることが前提で、サイトを公開して、直接、間接的に何らかの利益をあげているわけですから、閲覧者にそっぽ向かれるとサイト自体を公開している意味や必要がなくなります。
趣味でやっている(もしくは金の出所的に閲覧者はどうでもいい)ようなサイトの管理者であれば、ユーザーにサーバーの資源を使いすぎるなと強いることは気にならないかもしれませんが、そういう人たちが、サーバー側でどうにでも出来るようなことをマナーとして押し付けて、閲覧者に「RFCだかなんだかしらないけど、よく分からないマナーを押し付けられて、不便を強いられるWebってクソだよね」のようなネガティブなイメージを与えられても、、、と感じます。
親コメント
Re:ここは、関係者に (スコア:1)
多くなってきたんですが、
パフォーマンスに関するパラメータをバイナリパッケージの
デフォルトの設定のまま運用していることがほとんどです。
サーバーを適切にチューニングしてあれば、
ケースバイケースではありますが、
リソースが占有されている時間が短くなる分
クライアントの同時接続が多い方が
サーバー・クライアント共にパフォーマンスがあがることがあります。
両方を適切にチューニングできる人ってそうはいないと思いますし、
数値上のパフォーマンスと体感上のパフォーマンスって別なので
この辺のノウハウが一般的になってくれればなぁと思うことが
しょっちゅうです。
親コメント