「家庭用NAS＋サインはVGA＝デスクトップ機」記事へのコメント

件のサイトが

[yanagi (6075)]

件のサイトがslashdotedなようです。
土曜日の朝からサーバ復旧作業か(^^;
お疲れさまです

--
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ

Re:件のサイトが

[Anonymous Coward]

正直、個人の自宅サーバをスラドで紹介するのはひどくないだろうか。
貧弱なのが悪いとか、Webなんだからとかそういうのは置いといて。置いとくなってのは無しで。
まぁうれしい悲鳴なのかもしれないけど。

Re:件のサイトが

[Anonymous Coward]

件のサイトの管理人ですが、現在、80番ポートを封鎖中です。 サーバLANDISK＋回線ADSL 8M/1Mでは、やっぱり苦しかった。汗

pingとCache-control

[chanbaba (13080)]

>>ping eggplant.ddo.jp
>
>Pinging eggplant.ddo.jp [61.126.152.64] with 32 bytes of data:
>
>Reply from 61.126.152.64: bytes=32 time=107ms TTL=21
>Reply from 61.126.152.64: bytes=32 time=183ms TTL=21
>Reply from 61.126.152.64: bytes=32 time=103ms TTL=21
>Reply from 61.126.152.64: bytes=32 time=247ms TTL=21
>
>Ping statistics for 61.126.152.64:
> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
>Approximate round trip times in milli-seconds:
> Minimum = 103ms, Maximum = 247ms, Average = 160ms
>
>>ping slashdot.jp
>
>Pinging slashdot.jp [61.215.208.13] with 32 bytes of data:
>
>Reply from 61.215.208.13: bytes=32 time=84ms TTL=58
>Reply from 61.215.208.13: bytes=32 time=88ms TTL=58
>Reply from 61.215.208.13: bytes=32 time=88ms TTL=58
>Reply from 61.215.208.13: bytes=32 time=89ms TTL=58
>
>Ping statistics for 61.215.208.13:
> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
>Approximate round trip times in milli-seconds:
> Minimum = 84ms, Maximum = 89ms, Average = 87ms

今の時間帯でもそれほど込んでいるとは思えない。
ラーメン屋の紹介記事でも、記事が公開された数日だけ込むだけだろ。
後は込んだとしても高が知れている気がする。

あと、俺wikiには疎いが、キャッシュコントロールでmax-ageを1時間くらい指定すればかなりトラフィック減らせるのでは？
「HTTP/1.1 304 Not Modified」を返す奴ばかりを連呼しているのが現状だから。
特に、画像やcssとかなんて頻繁に変わるものじゃないし。
それと、頻繁に変わる http://eggplant.ddo.jp/www/pukiwiki/index.php とかって、
>Cache-control: no-cache
>Pragma: no-cache
が必要なんだろうか？
Cache-control未対応のブラウザ様に「Pragma」の「no-cache」に付き合うように「Cache-control: no-cache」にする必要は無いのでは？
ちなみに、俺は（借りているレン鯖で）掲示板では
>cache-control: must-revalidate, max-age=0
を使っている。「must-revalidate」を認識しないブラウザ様に「max-age=0」も指定していて、毎回チェックを強要している。
Last-ModifiedとETag吐いて、キャッシュさせ変更無ければ「304 Not Modified」を送る感じ。
no-cacheをmust-revalidate, max-age=0、何も指定していない画像とかはmax-age=3600とかの方が良いんじゃないの？

Re:pingとCache-control

[Anonymous Coward]

てか、今臨時サーバに切り替えてあるからでしょ。 LANDISK200MクラスのCPU、メモリ64M　→　iMac G5 処理能力が一桁ちがうし。

Re:pingとCache-control

[chanbaba (13080)]

それは知っているが、#768044では
>日を増す毎にアクセスが増加し、慢性的な回線飽和状態にあります。
>無料でコンテンツの置き場所等を提供していただける方を募集中です。
http://eggplant.ddo.jp/www/index.html
の話が出ていたよね。
飽和は「回線」では？
と言うか、俺キャッシュコントロールの話をしているが、アクセス数やトラフィックはかなり減らせるはず。
/.で話題になったから云々は、一時的な物なんじゃないの？
あとは、元々「慢性的な回線飽和状態」だったんだよね。
だから、肝のコンテンツのキャッシュコントロールを弄る話をしたのだけど。

Re:pingとCache-control

[minek (14559)]

　回線の飽和といえば。

　ADSLで鯖をたてると、「くだり」＝リクエストはがんがん届くんだけど、「のぼり」＝レスポンスはそこそこしか返せない、という状況に陥ります。また、だいたいどんなプロトコルでもリクエストとレスポンスは圧倒的にレスポンスの方がサイズが大きいですから、そのしわよせがルータにかかる事が珍しくありません。

　臨時拠点のVPN導入で、光開通までアクセスラインにADSLを使っていたら、頻繁にルーターが未応答になって大変なことになったのを思い出しました……。

Re:pingとCache-control

[chanbaba (13080)]

>　ADSLで鯖をたてると、「くだり」＝リクエストはがんがん届くんだけど、「のぼり」＝レスポンスはそこそこしか返せない、という状況に陥ります。また、だいたいどんなプロトコルでもリクエストとレスポンスは圧倒的にレスポンスの方がサイズが大きいですから、そのしわよせがルータにかかる事が珍しくありません。

そうだけど、それを何とかしようと努力した方が俺は良いと思う。
ちなみに、 http://eggplant.ddo.jp/www/pukiwiki/ を表示し（IEだと）「ctrl+更新」でファイルを読み直した後、「更新」をすると、htmlファイルの他に19個読むが、その殆どのリクエストは470バイト程度で、レスポンスは250バイト程度。
htmlファイルも最終更新日とか吐き出せば、更新が無ければ同様のサイズのレスポンスで済む。
また、他に読んだ19個はmax-age=3600とか指定しておけば、「更新」ではチェックに行くが、移動して来たときには更新チェックにすら来なくなる。
そうやってトラフィック絞った方が良いと俺は思う。

ついでに、
タレコミの http://eggplant.ddo.jp/www/pukiwiki/index.php?LANDISK%A4%C7%C1%E6%A4%AE%A4%A4%A4%C7%A4%CA%A1%C1%A2%F6 で読んだキャッシュがあった為か、 http://eggplant.ddo.jp/www/pukiwiki/ で読んだとき他の19ファイルのETagの値が違いapacheは通常通り全部レスポンスする。
しかし、最近のIEは最終更新日変更無しの場合はETagが違っても、途中で読み込みを中止し、それはキャッシュされず古いのを使う。
その為、毎回ETag値はマッチせずに毎回ファイルを全部送る羽目になる（小さいのでIEが止める前に全部送ってしまう）。
IEの実装がRFCに沿っていないのが原因と思われるが、IEの実装は考慮した方がトラフィックは少なく出来るので、やっぱ考慮した方が良いと思う。

Re:pingとCache-control

[Anonymous Coward]

無料でコンサルしていただいて申し訳ないです。
恐らく小さなファイルというのは、wikiのアイコン画像だと思われ。max-age=3600を指定すれば、それらファイルの再送信が抑止されるということですね。試してみます。

平常時の慢性的回線飽和の主原因は、サーバ内におかれたギガクラスのコンテンツをツールで根こそぎDLする方が後絶たないためでありまして、apt-get以外のツールでアクセ

Re:pingとCache-control

[iwa (2980)]

とりあえず、デカくて静的なファイル(要は*.deb)はsourceforgeあたりに置くのが吉かと。sshでアクセスできるので、rsync一発で同期できますし。
おいらは回線飽和を危惧して、最初からsourceforge.jpに逃げますた。 [osdn.jp]

乙であります

[Saitamanist (24995)]

お疲れ様です。
うちも自鯖立ててみたいとは思うけど、ADSLの貧弱な上りが気になって立てられないんすよね。。。IP電話も一緒だし。

# ぐぐるキャッシュの見られない会社にいるのでID
# でも2chは見れる謎

--
まぐろたべたい

よくやった！

[Anonymous Coward]

痛みに耐えてよくがんばった！感動した！！
これからも面白いネタを提供してくだされ。

上の人がスラドに個人サイトを掲載するのはどうか？とありましたが
半分賛成～、
つーかここに載せる前に、該当サイトの担当者に連絡するくらいの
努力はしましょうや＜スラドの管理人

Re:よくやった！

[Anonymous Coward]

うーん、個人サーバ／サイトと何らかの団体サイト／サーバ
厳密な線引きってできますかね？
しかもリンクに許可って、
無断リンク禁止を笑うのがココの流儀でしょ。

/.や2ch、ニュースサイトなんかがある以上、
おもしろいネタを公開したら人が集まる。
それだけ価値のある情報なんだから。

ま、潰れないサイトに移るのも、面倒だから放置するのも
公開する人の権利ですしね。
もったいないなぁ、と思う人がいるなら交渉して
ミラーしたげるのも自由。

Re:よくやった！

[Y.. (7829)]

今回はDDNS使ってるのがアドレスから分かるから
個人サーバっぽいってのは比較的わかりやすい方だと思う

まぁ、個人だからといってリンク許可とるってのはなんか違う気がするけど
転載許可とってスラドのサーバに画像だけでも置いておくとかできれば
slashdotedにもなりにくくなるんじゃないかなぁってふと思った

Re:よくやった！

[Anonymous Coward]

無断リンク禁止は、情報の流通を阻害しているから笑われるんだよ
その目的を見失って「リンク自由」と声高に叫んでサイトを潰し
結果情報が見れなくなるんじゃ本末転倒
他のコメントを見てごらん、一体どれだけのコメントがストーリーの本質を語っている？
皆、情報が得られないものだから、ロクなコメントがつきやしない

リンク自由には諸手を上げて賛成だが、自由って事はそれなりに気を使わなきゃ行けない事が増えるもんだよ

Re:よくやった！

[herewe (21291)]

>しかもリンクに許可って、
>無断リンク禁止を笑うのがココの流儀でしょ。
それは情報の開示に対する流儀ではないですか？
「ネットに繋ぐならどんな高負荷にも対応しておけ」
なんて流儀はネットへの情報公開の敷居を高くしてしまいます。

>ま、潰れないサイトに移るのも、面倒だから放置するのも
>公開する人の権利ですしね。
公開する側の負担だけやたら高くないですか？
リンクする側でも配慮できるのなら、それに越したことはないでしょう。
価値のある情報の発信源を潰してしまわないようにする工夫くらいはやってもいいのでは？

Re:よくやった！

[Anonymous Coward]

>「ネットに繋ぐならどんな高負荷にも対応しておけ」
>なんて流儀はネットへの情報公開の敷居を高くしてしまいます。
>公開する側の負担だけやたら高くないですか？
>リンクする側でも配慮できるのなら、それに越したことはないでしょう。
>価値のある情報の発信源を潰してしまわないようにする工夫くらいはやってもいいのでは？

今のご時世、無料のサーバなんていくらでもあるし、
自前でサーバ

Re:よくやった！

[Anonymous Coward]

>価値ある情報が失われない良い方法は無いもんか、と。

まあ自分の情報でも外部の情報でもローカルに保存しておくしかないね。
もう一度見たいと思っても既に無くなっているというのは
メーカーの技術情報で良く経験してます。

#ローカル検索しておける様にしておくとかなり便利。

Re:件のサイトが

[Anonymous Coward]

考えようによっては、アクセス負荷テストにもなるな～ ということで、ポートをオープン。そのまま放置で外出です。

Re:件のサイトが

[lss (2577)]

そんなときは、ぐーぐるきゃっしゅ [216.239.63.104] です。

Re:件のサイトが

[Anonymous Coward]

http://eggplant.ddo.jp/www/のキャッシュ [66.102.7.104]
>日を増す毎にアクセスが増加し、慢性的な回線飽和状態にあります。
>無料でコンテンツの置き場所等を提供していただける方を募集中です。
確かに問答無用で止めを刺した感が・・・

Re:件のサイトが

[Anonymous Coward]

後は、coral [srad.jp]
とかも使えばグットよ。

http://www.coralcdn.org/
http://itpro.nikkeibp.co.jp/free/NNW/NETHOT/20040924/150340/

Coral

[Anonymous Coward]

件のサイトの管理人です。試しにやってみました。
負荷削減効果のほどは分りませんが、正しくページが表示されました。（当たり前か！）
coralとは、サーバの負荷が（コンテンツの質に比例して）軽減される、そういったシステムなんですね。
試していませんが原理的にはLANDISK用apt-lineもCoral経由でアクセス可能かな？
勉強になります。

Re:件のサイトが

[tarosuke (2403)]

むしろそういう問題じゃないか？
つまり、リンク張るならキャッシュにもってことで。
# 画像は見れんが。

Re:件のサイトが

[gunner (8999)]

個人で細々と自宅鯖を営んでいる側としては頭の痛い問題ですね。
急な大量アクセスに対応使用とすると明らかに回線維持費が高騰しますし、
大手側が掲載前に連絡を入れてもらえれば併用している他のスペースに移したりの準備も出来るのですが…

正直、Webなのだからリンクは自由といっても突然の紹介と
それに伴う大量のアクセスはF5連打とさして変わらないように思えます。

#
#当方の自宅鯖(通常非公開)は幸いにも今のところ無事な模様
#

--
#状況はいつも最悪、でもそれが当たり前

Re:件のサイトが

[tarosuke (2403)]

んー。なんつーか、これは直接アクセスを基本とするhttpの欠陥な気がして来た。たとえばあまり変化しないコンテンツは複製しても問題はないわけだから、P2P的に分散キャッシュするカラクリとかがあればいいんじゃないかと。見た(落とした)奴が自動的にキャッシュに加わって自分のキャッシュを公開するとかね。
# 配布元にHEADすればキャッシュが最新かどうかもわかるし。

Re:件のサイトが

[gunner (8999)]

突発的連続アクセスについてだけならプロクシを各ISPが用意しておくとかで
ある程度の緩和は出来るかもしれませんが、
セキュリティとかまで考えるとややこしい問題ですね。

本来こういう使い方を想定していなかったシステムなのだから仕方ないとはいえ
コンテンツ提供側に相当負担を強いていると思う現状はいかがなものか…

#
#ネタが違う部分でウケたので凹み中
#

--
#状況はいつも最悪、でもそれが当たり前

Re:件のサイトが

[Anonymous Coward]

インターネット上にサーバーを置いた時点で、様々なリスクがあるという事を想定しなきゃならんのではないでしょうか。
別にスラドで紹介されなくても様々な可能性があるわけだから、
>貧弱なのが悪いとか、Webなんだからとかそういうのは置いといて。置いとくなってのは無しで。
って、気持ちはわかるけど、それを置いといたらもっと大切な事が語れなくなっちゃうんじゃないかなぁ。

Re:件のサイトが

[Anonymous Coward]

一方的に「対策していなかったほうが悪い」というのは如何なものかと。

スラドで記事を公開する前に、対象のサイトに一報する
（個人サイトの場合は、/.ed によるDoS被害が発生しうる事を
　伝えた上で許可を貰う）くらいのことはすべきではないでしょうか。

こういうのは「ネチケット」に属する事だと思います。

Yahoo!ニュース

[nezuku (25740)]

Yahoo!ニュースは最近対策を講じたみたいですね＞外部リンクの過多アクセス

ニュース記事に共に載っている外部リンクのリンク先が、一旦
Yahoo!内の確認ページになっています。で、アクセス数が多い
サイトの場合、リダイレクトされず、アクセス過多でページが
表示されない可能性があるという旨が表示されます。
少し前までは個人、小規模Webサイトのみの対策だったようですが、
最近はすべてYahoo!内のリンクになっています。

スラドでこのような事態が起こったわけですから、
Yahoo!にリンクが貼られた暁には…

Re:Yahoo!ニュース

[Anonymous Coward]

Yahooのトップページに掲載されたニュース記事にリンクが貼られるととんでもないことになります。秒間1000～2000リクエストぐらい食らいますのでADSLどころかT3クラスの回線でもちょっと大きめの画像やFlashがあるだけであっという間に回線パンクします。

職場の話なので絶対AC

Re:Yahoo!ニュース

[Elbereth (17793)]

Yahoo!とかGoogleのニュースに載った地方新聞のサイトが
大変なことになってるってのはしばらく前はよくありましたねぇ。

Re:件のサイトが

[Anonymous Coward]

別に「対策していなかったほうが悪い」って事では無いでしょう。
すんごいアクセスがあって大変な事になってしまった。それでもいいという人であればそれでもいいだけの事であって、そんな事もありえるって事を想定していなきゃって事であって、そんな事を対策しなきゃだめってわけじゃない。

Re:件のサイトが

[Anonymous Coward]

では、その一報するのは誰がするんですか？
タレコミを書く人ですか？違いますよね。掲載が確定していないわけですから。
編集者が配慮するか否かってところじゃない？
今の編集者達を見る限り、その配慮はないだろうが。

例えば、タレコミ本文ではURL書かずに、末尾に参考程度に挙げて、掲載するなら一方

訂正機能がまともに働かないと言う事は・・・

[Anonymous Coward]

>>例えば、タレコミ本文ではURL書かずに
>>末尾に参考程度に挙げて、掲載するなら一方入れて挙げて下さいとか書くか？
極端に言えばそうなる。
が言わずともその部分の折り合いをつけるのが掲載者側なんですよ。
その体制がないなら、タレコミ情報をダイレクトに
のせるだろう？

Re:件のサイトが

[Anonymous Coward]

>インターネット上にサーバーを置いた時点で、様々なリスクがあるという事を想定しなきゃならんのではないでしょうか。
>別にスラドで紹介されなくても様々な可能性があるわけだから、
気にしなさるな。
個人用サーバーなんぞ下手な対処するより

Re:件のサイトが

[Anonymous Coward]

過去何回かURLを張り付け(られ)た、私的には全然OKです。
負荷があまりにも酷くなったら転送量の削減、アクセス数の制限、コンテンツの分散などで対応します。
「切断」という奥の手もありますし。

# 特にネタが無いのでACで