アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
ここは、関係者に (スコア:0)
実際のWEBサーバの管理者さんたちの意見をどうぞ↓
404 (スコア:3, おもしろおかしい)
Re:ここは、関係者に (スコア:2, おもしろおかしい)
「ウチはほとんどテキスト」
図表など、画像を使わないことにはどうしようもないところだけ画像使用。
「詳細」「前ページ 1 2 3 ... 次ページ」ごときをグラフィカルなボタンにするなんてトンデモナイ。
背景画像？ な、な、な、なんて贅沢な。
なに、見栄えにもこだわりたい？ であれば…。
「つまらないコンテンツしか置かない」
これ最強。
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, すばらしい洞察)
職業としての管理者、それだけでなく、サイトそのものを公開することを決定し、管理者に対価を払っている団体、個人は、プリインストールソフトをデフォルト設定で使うような一般的な閲覧者がいてくれることが前提で、サイトを公開して、直接、間接的に何らかの利益をあげているわけですから、レジストリをいじるような一部の自称マニアを優遇して重くなって、一般的な閲覧者にそっぽ向かれるとサイト自体を公開している意味や必要がなくなります。
趣味でやっている(もしくは金の出所的に閲覧者はどうでもいい)ようなサイトの管理者であれば、ユーザーにクライアントの設定を変えろと強いることは気にならないかもしれませんが、そういう人たちが、サーバー側でどうにでも出来るようなことを押し付けて、閲覧者に「なんだかしらないけど、よく分からない設定をいじらないと遅くて、不便を強いられるWebってクソだよね」のようなネガティブなイメージを与えられても、、、と感じます。
Re:ここは、関係者に (スコア:0)
Re:ここは、関係者に (スコア:0)
まず、そもそも、商売でやっているのであれば、少数の「マニア」が10張ってきたところで(しかも、転送効率などが悪くなるわけでもなく、総転送数が増えるわけでもなく)、それで重くなるようなマージンが少ないシステム自体がおかしいわけで、結局のところ、閲覧者が直接、間接的なお客様である以上、システム側で対処すべき問題という話ですよねということ。
そして、そのマニアのやり
Re:ここは、関係者に (スコア:1)
何も設定していない状態だと各接続に均等に帯域が割り当てられるので、たとえば一般のお客様が２並列、マニアが１０並列で接続した場合、一般のお客様を1/5に冷遇している状態になりますよね？そもそも、優遇されないなら増やす意味もない。
「お客様第一」と「システム側で対処」という目指すところは同じです。
よい例えになるかどうかわかりませんが、
「1000円以上お買い上げの方おひとり様１個」のシステムのまま、並び直しを推奨してレジを増強するよりは、
「1000円につき1個」にして、2000円買ったら1回のレジで2個買えるシステムにしたほうがお互いメリットがありませんか？
その場合、並び直すお客様は何ら得しませんが。
>(しかも、転送効率などが悪くなるわけでもなく、総転送数が増えるわけでもなく)
解説はしないがダウト。
# (もしくは金の出所的に閲覧者はどうでもいい)は、元は(もしくは金の出所的にサーバをいくらでも増強できる) と書いてた。
Re:ここは、関係者に (スコア:1)
「1000円以上お買い上げの方おひとり様１個」のシステムのまま並び直しを推奨してレジを増強するよりは、
->
「1000円以上お買い上げの方おひとり様１個」のシステムで、子や夫を別のレジに並ばせるのを推奨してレジを増強するよりは、
「1000円につき1個」にして、2000円買ったら1回のレジで2個買えるシステムにしたほうがお互いメリットがありませんか？
Re:ここは、関係者に (スコア:0)
Re:ここは、関係者に (スコア:0)
>マニアが１０並列で接続した場合、一般のお客様を1/5に冷遇している状態になりますよね？
>そもそも、優遇されないなら増やす意味もない。
そもそも、許容接続数が常に一杯で待ち行列が出来ている状態ならまだしも、そんなキャパシティプランニングで運用するようなアホは居ないわけで、常にあいている状態とした場合、2並列接続してくるクライアントは10並列接続してくるクライアントよりも優遇しているという言説はおかしいでしょう？
また、
Re:ここは、関係者に (スコア:0)
その辺は職業鯖菅的にはどうですか？
Re:ここは、関係者に (スコア:0)
そういう提供側の損得勘定の部分からごちゃまぜで、お客様にマナーという名目で押し付けるのが商売として正しいの？
Re:ここは、関係者に (スコア:0)
ですがRFCにある以上それに従うのが正しいことにされてしまいます。
そこで提案ですが、RFCとして出してみたらどうですか。IETFで認められればここで反対論を張っている人達も認めざるを得なくなるでしょう。
Re:ここは、関係者に (スコア:1)
多くなってきたんですが、
パフォーマンスに関するパラメータをバイナリパッケージの
デフォルトの設定のまま運用していることがほとんどです。
サーバーを適切にチューニングしてあれば、
ケースバイケースではありますが、
リソースが占有されている時間が短くなる分
クライアントの同時接続が多い方が
サーバー・クライアント共にパフォーマンスがあがることがあります。
両方を適切にチューニングできる人ってそうはいないと思いますし、
数値上のパフォーマンスと体感上のパフォーマンスって別なので
この辺のノウハウが一般的になってくれればなぁと思うことが
しょっちゅうです。
Re:ここは、関係者に (スコア:0)
接続に関する期待には応えるべき。
＃10接続張りたいならば、「わかりました、こちらも接続できるよう頑張ってみます！」
＃であるべきと言う事。
接続が出来ないようなサーバー君ならばKernelチューニングを最大限してそれでも
足りなければ、サーバー増設です。
とADSL上の固定IPでＷｅｂサーバーを運用している会社の管理者さんは申しております。
Re:ここは、関係者に (スコア:0)
ユーザに快適な接続を提供したいのであれば、
まず回線の増速を検討しましょう。
釣られたので AC
Re:ここは、関係者に (スコア:0)
首都圏で駅前であってもありますし。
128K専用線とかにくらべればADSLの1M等でも十分早いとおもうけどね。
Re:ここは、関係者に (スコア:0)
ADSLのUP速度って1Mだっけ？512kだった記憶が。
それともDownの速度によって変わる？
# 自分専用自宅鯖なのでそれほどUP速度を気にしたことが無い
# ぐぐってもそれらしい答えが見つけられなかった
Re:ここは、関係者に (スコア:0)
＃速度が保障されているわけではないけどね。