レス数が1000を超えています。残念ながら全部は表示しません。

[深刻] ２ｃｈ負荷問題ふたたび勃発

1 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:05

８・２６問題が再浮上かも。
http://teri.2ch.net/test/read.cgi/accuse/1011385033/
「いよいよ　何らかの手を打たなきゃどうにもならん状態になってきたようです」

関連ネタ
http://pc.2ch.net/test/read.cgi/tech/1002820903/360

22 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:13

>>18
負荷って言っても何の負荷かによるけれども
（てか、wでみたときの負荷？iostatで見たときの負荷？netstatで見たときの負荷？一体なあに？）
レスポンスは落ちるだろう。
でもreadまちのコンテキストがいっぱい並ぶのでスループットの下がり具合は
どうだろうか。

要はレスポンスの落ちこみ方によるんだな。
バッファキャッシュの当りかたがよくなって案外落ちなかったりしてね・・・

23 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:14

>>20
今回の改造の目的は転送量の削減でも負荷の軽減でもないからじゃない?

24 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:15

牡蠣→課金らしい。

25 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:32

無知でなんだが、dat直読みの場合ってgzip圧縮かかるの？
かからないならread.cgi使う事で転送量は多少減るんじゃない?
かかるなら...意味ねーな。

26 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:38

>25 こんどはCPU負荷で落ちるから。

27 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:55

>>24
カーカキンキン、カーキンキン？
某ｃｈじゃあるまいし。

28 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:58

寄付金集めればいいじゃん。
結構集まるでしょ。

29 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:03

レベルの高いLinux板に解決してもらおうよ。

30 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:03

１クライアントＩＰごとにトラフィック量を細かく制御する
ことができればいいんじゃないかなぁと思いますけどね。
こういうの、サーバレベルで可能なのかなぁ。

31 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:04

>>28
それは 1ch というんでは。

32 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 00:08

要するに今回の目的は、DAT直読みで課金ってことですか？

33 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:17

あぼーん禁止にすれば差分読むの簡単になって転送量が減るのでは？

34 ：名無しさん ：02/01/20 00:23

>>32
> 要するに今回の目的は、DAT直読みで課金ってことですか？
そういう方向みたいですね。

ID:pikopikopo---n@tora3.net
PASSWORD:detaramenahito

35 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:26

負荷問題への提案

1. CGIの改善 (read.cgi改良スレ読んでないんですぅ、が)
　そろそろ C使いに、効率的なCGIを作ってもらう時期.

2. サーバ構成の改善
　クラスタリング ＋ Layer4スイッチ ＋ キャッシュ・サーバ
　みたいな構成にして、板毎のサーバ分割から、動的負荷分散へ
　移行してみてはいかが？
　＃ちょっと萌えるテーマだ.

3.ビジネス・モデル
　i-mode 1000円っつうのはシャレにもビジネスにもならん気がする.
　とりあえず、金取れる所から、小額(200〜300円/月)でもとる方が、
　現実的だと思う.
　あと、「コミュニティ」以外の体裁を整えて、付加サービスとして
　２チャンネルがついてくる、という形も、検討すべきだと思う。

36 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:37

とりあえず、広告でもクリックしてみよう。

37 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:49

>>36 十回程クリックしてみましたが何か？

38 ：35 ：02/01/20 01:04

って既にC言語なんだ.

http://www.gedoh.org/aki/2ch/current/bbs/

現状把握に時間がかかりそう>>俺方面

39 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:05

>>35
> 　そろそろ C使いに、効率的なCGIを作ってもらう時期.
今も C だよ。
もっと効率的にしろ、ってこと?

40 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:06

http://www.yakin.cc/
88.9 Mb/sか。たしかにヤバイ状態かもしれない。

41 ：35 ：02/01/20 01:15

ﾁｮﾄすまん。

read.cgi改良スレッド３
http://pc.2ch.net/test/read.cgi/tech/1002820903/

と話が錯綜して、よく把握できないっす。

42 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:25

有料化したら無料の所のドミノ倒しが再現するだけでは？

dat読み制限ってことは、
2ch依存症のヘビーヲタのリロードがかなりの割合を
占めてるんだろうね。
という漏れもxyzzy+2ch-mode中毒者（汗

43 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:38

>>40
非営利なサイトで88.9Mb/sは尋常ではないわな。
下手なサーチエンジン系サイトより多いかも。
クラスタリングや負荷分散が必要なレベルに
なってきてるっていることは間違いない。

44 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:40

いや、アレだろ。read.cが単独でlistenして、1プロセス毎に
30クライアントくらいずつまとめて面倒みるのが‥‥

45 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:40

dat読み課金だってyo!

46 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:42

1ch有料化と時期同じく2chも有料化。
あぶれた難民は在野に下るなんてシナリオどう？

ちたぁ粛清されんじゃねえか？

47 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:46

＞dat読み課金だってyo!
ブラウザで見れば関係ありませんね : )

48 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:49

>>43 キャッシュ・サーバも有効そうです。>>再読み込み方面

まっとうな専用キャッシュ・サーバは、
結構古めのHWに専用OS使っていて、スループットが高そう。
だけど、むちゃくちゃ高価。

っつうわけで、安くて高性能なキャッシュサーバを立てる
方法はないのでしょうか？

49 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:49

どれだけ負荷分散しようが、
同じサーバー群からデータが出ていくわけだから意味ないのでは？
それより、2ch専用のcacheサーバプログラムをつくって配布するべきだろう。

50 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:53

あと、祭り発生時、読み書きが激流のように発生している時、
サーバ←→キャッシュ・サーバ間のトラフィックを押さえる
方法はないのでしょうか？
HTTPの範囲指定GETを使うとか、専用プロトコルを使うとか..

51 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:56

>>49
ユーザ側に配布するのですか？
あるいは、ミラー・サイトやアクセス・ポイントみたいな話ですか？

52 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:58

カキコできるスレ →無料 誰でも読める
DAT落ちのスレ →有料、monazilla系のツールでしか読めない。IDとパスが必要
html化した過去ログ →無料 誰でも読める

53 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:00

！！！＞http://teri.2ch.net/test/read.cgi/accuse/1011457309/

54 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:09

>>40
1/14〜15のレコードは明らかに稲垣祭りだね。
冬厨時期と少しずれていたのが幸いだったかもしれない。
これが１週間早かったらと思うとゾッとする。

55 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:09

>>50
read.cgi側で、response headerに付けるキャッシュ有効期限を長くしたらいいんじゃないの。

>>52
「dat落ちのスレ」の何が問題なんだろう???
(「dat直読み」自体が問題なのかな。広告が出ないので)

56 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:12

>>55
> 「dat落ちのスレ」の何が問題なんだろう???
この課金法だとブラウザの人にとってはいままでどおりってことじゃない？

57 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:15

88.9MB/Secの転送量・・・
サーバ→クライアントの下りだけ考えてみると、

・http://pc.2ch.net/unix/のリロード(HTML部のみ) 76KB
　→約1198回/Secの転送

・このスレの最新50リロード(HTML部のみ) 14KB
　→約6503回/Secの転送

BIGIPだのキャッシュ鯖だの要るな確かに。

58 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:17

どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
f4

59 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:19

>>56
そりゃそうなんだけど、
「専用ブラウザの人の『dat落ちスレ』負荷」なんて問題になる?

60 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:21

＞どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
＞あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
それってまさしく、８月破綻まえのモデルでは‥‥

61 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:21

>>55 キャッシュ有効期限を長くする
最新情報が見えなくなる→リロード→負荷増大

62 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:22

>>19

63 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:23

>>19がどうした?

64 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:25

UNIX板の面目を果たすために、
安価かつ高性能なキャッシュ・サーバの
構築方法を提案できたらいーな。

レンタル鯖 or WebProg板方面逝った方が、情報収集しやすいのかな？

65 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:27

トリップ持ってる2ch.netの人間が、要件を整理して提示しないと何ともならんな。
どこかにあるのかね。

66 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:27

＞64
行くなら通信技術板じゃないの？

でも正直今の2chはロードバランサやキャッシュサーバで
なんとかなるレベルを超えてる気がする…。
Big-serverも変なプライド捨てて素直に制限かけるべきと思う。

67 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:30

いずれにせよ対策方法自体を2ch.netの外にもっていかんと
前の破綻前と同じ路線の対策しか打てない
↓
今すでにキャッシュの有効期限決め＋データ圧縮をやってるものが
こうして動いている
↓
httpdとOSに手入れず、
gzip以上に転送データを小さくする方法があればいいけど。
↓
ロードバランサーでは2ch.netの出入りパケットが減るわけがない
（特定の板の処理負荷を減らすことができるだけ）
↓
キャッシュサーバを置いてもクライアントへ出ていくデータが減るわけではない
（httpdの処理負荷減らすだけになる）
↓
あぼーん

68 ：sage ：02/01/20 02:37

>>57,>>66
祭り発生状態の板/スレだけ、
ピンポイントで制限 or キャッシュ＋負荷分散できたら、
他の板の住人はちったーしやわせになれるんでわ？

69 ：sage ：02/01/20 02:38

>>67 回線占有幅が問題なのですか？

70 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:41

主に汎用ブラウザ(IE,NN)方面について、
HTTP圧縮はサポートしていないのでしょうか？

71 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:44

＞70
その話は5ヶ月前に既出。
すでにread.cgiが実装してる

72 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 02:47

パケットシェーパー入れるのが手っ取り早いんじゃない。

73 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:49

ひろゆき曰く、祭り自体は大した問題ではない。
その後に新参者が定着し転送量が高値安定するのが問題。

gzip化で時間稼ぎの間にP2P実用化、のシナリオ通りには
やっぱ行かなかったね。半年しか持たんとは。

74 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:50

とりあえず、ここいらみて8月危機を復習しとけ。
http://hpcgi1.nifty.com/BWP/diary.cgi?action=view&date=20010830

75 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:52

しかし逆に考えれば
これだけの巨大な情報システムが
草の根ネット的に無料で運営されてきた
というのもすごいような

76 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:53

結局今回問題なのは転送量かサーバ負荷かどっち？
サーバ負荷ならあの人の言うとおり mod_perl 入れれば少しは
マシになるのでは。

77 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:56

つーかさ，寒波募集したら？

78 ：49 ：02/01/20 02:57

>>51
後者です。
だれか作ってみない？

79 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:57

「転送量」は単なる指標に使っているだけなのか、
それとも「通信回線の帯域圧迫」>>「サーバのCPU、I/O負荷増大」と理解していいのか?

80 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:59

UNIX板で2chの問題を解決しようというのは反対。
また変な感謝age荒らしが来たらたまらん。

81 ：山師 ：02/01/20 03:01

CPU足すわけにもいかんし
エンタープライズ系が使えるわけでもないし
サーバー増やすのは限界だし
modぶち込むには、HE社の技術を説得せんといかんらしいし（できるかもしれないけど、交渉が必要　すぐにはできないらしい）

82 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:01

>80
おまえ一人の殻に閉じこもってろよ。
他人とコミュニケーション取ろうとするな。

83 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:06

>>80
今回はまだ何もしてないのに感謝age荒らしの心配なんかするな。

84 ：呼んだ？ ：02/01/20 03:10

感謝age

85 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:11

こういう２ｃｈの状態はインターネット業界みんな起こりうる状態で
あって、注目に値すると思うぞ。

ただ単純にサーバ増やしたり、回線を増やすことを考えるのではなくて
少ない資源でどう対処するかを考える事も技術の進歩になるのだから。

86 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:15

ITバブルの頃って、
取らぬ狸の皮算用で過剰投資が問題になったが、
現実にビジネス・モデル＆負荷問題が起きている例で、
どうやって問題解決していくか、
漏れもケース・スタディーとしてすごく興味がある。

87 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:16

あのflashでいってた、「いつか限界がくる」の
その限界が来そう、って事だろ。
鯖の力を増やせば、その分帯域も喰うから、
いっぱいいっぱいの状態にしてある、って話も
きいたぞ。

88 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:18

つか、２ちゃん救うことに意義が見つけられない・・・

89 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:21

>>86
けど実際問題コードチューニングするのも限界があるし、
まして今安定稼動してるシステムに手を入れる暴挙なんて極力避けたいしなぁ。
負荷問題の解決方法は結局のところマシンのリプレースしかないと俺は思うんだけど。

90 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:24

SE or コンサル感覚でいくと、
結局ビジネス・モデルの確立が、
問題の根っこにあるとは思う。

３リオで、ギコネコ・キャラクター商品売って見るとか...

91 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:26

>>80,88
なんか自慢げな書き方だなあ。お前が2ch救えるわけでもないだろうに。
技術的に興味のある話題ってだけでいいだろ。

92 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:27

>88
>つか、２ちゃん救うことに意義が見つけられない・・・
そう考えずに、こういうケースが目の前で動いてるって
考えればいいんでは？

こういう状況ってなかなか作れるものではないと思うのだが。

93 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:31

まずは性能モデルでもつくってのんびり眺めてみては？
構成が見えんのがツライところだが。

94 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:36

>89
確かに。
でもまだやれることは本当に無いのだろうか。
インタラプタ言語をやめるとか、プログラムで無意味なループの
処理を最適化するとか、不必要なデータファイルを消去または、
DATテープに移すとか．．ｅｔｃ．

95 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:38

だいたい、半年前と状況は変わってなくて、
対策打ってその効果が目減りしただけ。

そろそろ技術うんぬんの話でもなくなってきた模様と思うが・・・

96 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:39

>44のとかどうよ。forkが1/40になったら、だいぶん効くと
おもわないか？

97 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:39

>>74 感謝!!

あと、こっちも参考になりました。
ttp://home.att.ne.jp/wind/monsta/ga/2ch_kiki.htm

98 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:41

>>95
やっぱりそうなんだろうか･･･。
俺もずっと考えてたんだけど、俺の頭じゃ･･･。

2chうんぬんはまあ、いろいろあるけど、
純粋に技術的におもしろいと思ってみてたんだけど。

99 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:41

>>94
それやっても通信データ量は削減されない それも半年前と同じ。
CPU使用量とDASD使用量をさげても問題は解決されないのです。
データそのものの大きさを減らす→利用者数が増加している局面では
　　　　　　　　　　　　　　　　効力に限りあり
データそのものの入出力回数を減らす→キャッシュされにくいデータを
　　　　　　　　　　　　　　　　　　扱う場合、あまり減らせないことが多い

100 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:42

>>96
効いてしまってますますデータ転送量が多くならないか？

101 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:44

read.cgiをmodにする。ってのはやっちゃいけないのか。。
apache捨ててhttpdを自前で作るってのは？

102 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:44

とりあえずLinuxやめてSolarisにでもしてみい。
元々Linuxは限界付近の挙動が怪しげな上に、kernel 2.2.20じゃSMP
マシン使ってる意味が無い(全部では無かったかもしれんが)。
2.4系はもっと怪しげだし。

103 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:45

過去ログへのアクセスは
googleのキャッシュ/web.archive.orgに転送。

104 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:46

そうなるとこのケースはサーバと回線を増やす以外方法がないのでしょうか？

105 ：102 ：02/01/20 03:46

あ、転送量の方も問題なのか。しつれい。

106 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:46

CGIでの要求応答で、2〜4回に1回、1秒ほどsleepするのはどーだろう。
毎回sleepされたらレスポンス問題になるが、
2〜4回に一回、ちょっと遅くなる程度であれば
案外人間気にしないんじゃないか？

107 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:47

で、プロセスが爆発して、メモリは足りなくなり、apacheはあっというまに
MAX_CONNECTIONまでいって、接続を待たされる、と。

108 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:49

>>106
レスポンス落とす系の案は前回の時にも出たが、夜勤に却下されてる。

109 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:50

半年前に削減したときよりも転送量が多くなってるということは・・・

半年前のサーバには、少なくともCPU高負荷が問題ではなかったはず。
（問題だったらそこが処理上のボトルネックなのだから、
　転送量が増加してまた問題にならないよね？）

110 ：山師 ：02/01/20 03:50

>>101
TUXとかかい？
http://ns1.php.gr.jp/pipermail/php-users/2001-September/002301.html
動的なページに効くかどうか知らんが･･･。

111 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:50

Linuxなら、RedHatのTUXとかいいんでないかい？（既出？）

112 ：山師 ：02/01/20 03:51

げ、かぶった

113 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:52

>106
アクセスピーク時には結構響きそうだな．．
＃CONNECTできない言いそう。

114 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:56

>>107
vmstatのreが増加してプロセスが増える分にはいんでない？
それにhttpd自体そんなにでかくないし、
あれってa.outのプロセスじゃないんでしょ？メモリは大丈夫。

が、httpdのプロセス数上限にひっかかるので、そこはそのとおり。

そういえば半年前はクライアント側の接続待ちもダメつってたね、
夜勤さん。。。

1. 転送データ量を減らす
2. その対処の結果、
　　ブラウザ側でがタイムアウトになったり、
　　レスポンスが顕著に遅くなったりしてはならない
3. 利用者数は月日とともに一様増加するので、
　　スループットも同様に一様増加する。

　　

115 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:58

>>110
PHPってすげー便利そうですが、本当にベンチマークいいんだろうか？
www.SourceForge.org とか、自前のUltra-10 にSourceForge 入れた
感想として、「レスポンス悪い」って印象持ったんですが。

TUX+PHPとか使うと違うのかなぁー。

116 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:04

DiskAccessをいかに減らすかって重要ですね。
Memoryをいっぱい積んでmfsって可能かなあ。

117 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:08

ピークになったら、106で書いてるsleepの代わりに、
「ごめんよ〜いま大変込んでるの・・・」
ってhtml返答してあげるつーのもだめ？
その返答が妙に短い時間で処理できてしまうと
その返答が数多く発生してナニかと思うのでnanosleepでms単位に調整とるとか。

したらブラウザで「接続できないぞ」「タイムアウトがでるぞ」ってのはないし、
サーバレンタル屋の気持ちになって考えてみても、
http的には問題なく伝送できているからウチのマシンのせいじゃないもんね
ってことでタテマエ上問題にはならんはず。

118 ：山師 ：02/01/20 04:13

>>115
PHPそこそこ早いよ。特にPHP4になってから劇的に早くなった印象がある
TUXもちょっと試したところじゃ確かに早い
でもTUX+PHPってどうかな？　安定性も未知数だし

その前に鯖屋（HE）が嫌がると思うけど

119 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:17

＞117
そんなものが宣伝になるか。

120 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:20

>117
>ピークになったら、106で書いてるsleepの代わりに、
>「ごめんよ〜いま大変込んでるの・・・」
>ってhtml返答してあげるつーのもだめ？
これを実現するにはやはり負荷分散装置が必要かなあ。

これは要するにサーバの状態を監視してて、いっぱいいっぱいならば、
違うサーバが「大変混んでるの」ページで応答することだけど．．う〜ん。

＃２ｃｈねら〜がそれで納得するかは疑問。

121 ：山師 ：02/01/20 04:22

>>106,>>120
リロードが多発して大して変わらないと思われ

read.cgi ver5.26+ (01/10/21-)