【２ちゃんねるビューア】　巡回機能の巻。Part3

>>212
1.5以前を弾いたら結構効果出ると思うっす

>>213
じゃー　大勢が決したら、もう一度呼んでくださいー
やりますので、

>>212
かちゅスレより。

312 ：名無し~3.EXE ：02/03/24 21:45
んー、ソース書き替え再コンパイルすりゃいいじゃんという話はおいといて。
実際やってない人のほうが遙かに多いだろうし。

で。
巡回機能を使ってなかった人は、たぶんお気に入りをポチポチクリックして、
順々に読んでいったと思うのね。
でもこれにもウエイトがかかるようになったと。
そうすると、同時にたくさん新しいタブで開くと回避できちゃうわけだよ。
Shift押しながらでも、設定で新しいタブで開くようにしてもどっちでもいいけど、
とにかく順々にポチポチ押していくのをﾔﾒﾃ、
一気に大量に新しいタブで開くようにするわけだ。
そうすると、待ち時間がなくサクサク読んでいけるようになる。

この行為って、順々にポチポチ押していくより鯖に負担かけてんちゃうかなぁと、
思ったりするわけです、ワシは。

でDLL氏がこれできないようにしたバージョンが1.5みたいです。

一部のかちゅユーザーに叩かれるな（ｗ

>>213
踊ってるの全滅だな・・・(´д`)

>>208　そこらへんは、負荷と転送量のトレードオフで
　どこでバランスとるべきなのかを迷ってるところと思われ。

>>217
そうよねー　
迷うってのもあるし、日々変わっていくってのもあるのよねー
時々刻々というか、

>211
えっとね。datやtxtをまるごと読むとね。gzipできるのね。
でも部分的に読むとね、できないの。これはmod_gzipの仕様なのね。
read.cgiのraw modeを使うと、部分的に読んでしかもgzipできるのね。
便利だけど負荷が高いの。わかる? わかってね。

>>211
gzipで落とすには、最後に「?raw0.0」って入れるはずですが、
rawを廃止するとできなくなるのではないですか？

それとも私の実験方法が違うのか…

>>219
subject.txtを部分的に読む、なんてしないと思う。
だから、いいんじゃない？

UpTime(choco) = 5:46am up 7 days, 22:11, 0 users, load average: 0.78, 0.78, 0.79
UpTime(vip) = 5:47am up 23 days, 7:53, 1 user, load average: 3.09, 2.83, 4.10
UpTime(love) = 5:46am up 33 days, 19:02, 0 users, load average: 29.21, 24.52, 22.80

love の相棒 curry にも入れた。

ふむ。つまり、

gzip圧縮して転送量の削減に成功した。
しかし、圧縮処理をするためにサーバー側の負荷が増大してしまった。

さてどうやってバランスを取ろうか、
ということですね。

>>223
ずーっと　同じような　アクセス数だったら簡単なんですけどね
噂では、もう２ちゃんねるばなれが進んでいるなんていうのもあったんで
期待していたんですが、　実際は。。。

転送量　と　サーバ負荷　のバランスもそうなんですが、
予算　と　ユーザ満足度　のバランスとか、　いろいろなバランスが。

＞夜勤さん
＞love の相棒 curry にも入れた。
　★持ちが他所逝ってるんで。
　アナウンス対応必要なのは下記？

【choco鯖】
ニュース速報7、地理お国自慢、壁、ピュアAU
ニュース速報、シャア専用、 顔文字、 モナー

【love鯖】
不倫・浮気、モーニングコーヒー、 過激な恋愛
男性論女性論、 純情恋愛、 同性愛、 カップル

【curry鯖】
競馬、独身女性限定、鉄道、電車、三国志＆戦国
ギャンブル、ラーメン、オカルト

【vip.bbspink鯖】
風俗、全般、半角文字列、アダルトＶ、半角二次元、半角かな

何回か弾かれたら、Kageがバージョンアップしてください・・・と表示するようになれば（以下略

>>226
そういう努力は、正直ユーザに期待したいですね。

>>186
夜勤さん、kabaで私キャップ使えないようです。。。

>>227
わざわざ、報告する必要がなくなると。
努力しないユーザーが大半で、今の各ツールのスレを覗くと・・

ホントに努力する人なら、そもそも自分でツール作ってるかも。

>>229=>>230
かちゅの作者が消えたのが、なんとなく判る気がする。

UpTime(choco) = 6:32am up 7 days, 22:57, 0 users, load average: 1.23, 1.27, 1.10
UpTime(vip) = 6:34am up 23 days, 8:39, 1 user, load average: 10.59, 8.76, 6.51
UpTime(love) = 6:32am up 33 days, 19:48, 0 users, load average: 21.11, 20.10, 19.87

作れるもんなら自分専用のをこっそり作りたい。

自作すると仕様変更に追われる日々

素人考えですが、kage が「かちゅーしゃ」の http アクセスを全部奪って、
キャッシュできるものは全部キャッシュするというということは出来ないでしょうか。

これは、クライアント側の処理なので本質的な解決にはなりませんが、
通常の使用時にもスレッド一覧の表示が早くなるなど、メリットは多いです。

(板の間をむやみに移動するの癖があるので、スレッド一覧の取得を毎回されたくないのです)

>>235　板の間をむやみに移動する人
そゆ人はかちゅじゃなくて
板をタブで表示できるゾヌやABoneに移行すべきだと思われ

>>135 にあっちいけといわれたが一応告知だけは。

UCK -Update Checker for かちゅ〜しゃ-
http://uck.tripod.co.jp/

UpTime(choco) = 6:45am up 7 days, 23:10, 0 users, load average: 0.98, 1.04, 1.05
UpTime(vip) = 6:47am up 23 days, 8:52, 0 users, load average: 61.78, 48.39, 25.02
UpTime(love) = 6:45am up 33 days, 20:01, 0 users, load average: 22.30, 21.47, 20.34

>>231
>>226=>>229
>>299≠>>230

違いますよ　ヽ(`Д´)ノ

>

UpTime(choco) = 7:05am up 7 days, 23:30, 0 users, load average: 1.08, 1.25, 1.11
UpTime(vip) = 7:08am up 23 days, 9:13, 0 users, load average: 265.69, 192.78, 141.31
UpTime(love) = 7:05am up 33 days, 20:21, 0 users, load average: 25.76, 22.98, 21.66

ねぇねぇ夜勤さーん♥
どうしてこんなに重いの？

>>242

多分、君がアクセスしているからでしょう。

>>243
......ｳﾜｰﾝ

いつもいってるけど、

１。　単に人が増えただけなのか。。。
２。　以前より長時間みんながつなぐようになったのか。。。
３。　一人一人のアクセス効率があがったのか。。。

ようするに　需要に供給が追いついていないということでして、

アタックとユーザアクセスって、切り分けできているのでしょうか？
＞ロードアヴェレージ
アタックとかかかってなくて、この数値なんでしょうか？

UpTime(vip) = 7:14am up 23 days, 9:19, 0 users, load average: 122.43, 141.38, 132.00
UpTime(choco) = 7:12am up 7 days, 23:37, 0 users, load average: 1.17, 1.03, 1.02
UpTime(love) = 7:12am up 33 days, 20:27, 0 users, load average: 30.69, 24.60, 22.48

アタック無しです。　>>246

>>248
了解です。
read.cgiとbbs.cgi、どっちの負荷がきついんですか？
ps -aux | grep cgiとかで、特定の瞬間のcgiのコール数とか、
出してらっしゃいますでしょうか？

転送量はyakin.ccのを信用していいんだよね。
ちょっと計算。。。

http://210.239.46.80/MapleSyrup/

Forbidden
You don't have permission to access /MapleSyrup/ on this server.


--------------------------------------------------------------------------------

Apache/1.3.20 Server at www.domain.co.jp Port 80


かちゅではなく作者行方不明のMapleSyrupが逝ってしまわれた模様です。。。

＞251
そこって自鯖じゃないの？よく分からんけど。

>>251
403なら調子悪いだけじゃないか？

グラフできたらいつでも更新するんで。
http://www6.ocn.ne.jp/~boyakkie/graph.png

http://www.yakin.cc/pv200201.html

bbs.cgi の方が　ずっと重い処理だと思います。
でも、アクセス数は。。。
上のページ見てくらはい。

>>251-253
スレッド型BBS閲覧用ブラウザ「MapleSyrup」　part3
http://pc.2ch.net/test/read.cgi/software/1016729822/l50
こちらに専用スレッドがありますね。
Indexes禁止してあるサーバで、、デフォルトのドキュメント
(index.htmlとか)削除しているって感じだと思います。

UpTime(choco) = 7:26am up 7 days, 23:52, 0 users, load average: 0.98, 1.08, 1.07
UpTime(vip) = 7:28am up 23 days, 9:34, 0 users, load average: 52.72, 103.15, 123.12
UpTime(love) = 7:26am up 33 days, 20:42, 0 users, load average: 17.98, 20.74, 21.81

>>256
知ったかぶりUzeeeeeeeee

>245
おそらく1と2と3だと思われます。

UpTime(choco) = 7:37am up 8 days, 2 min, 0 users, load average: 0.86, 1.03, 1.03
UpTime(vip) = 7:38am up 23 days, 9:44, 0 users, load average: 9.61, 47.29, 94.78
UpTime(love) = 7:37am up 33 days, 20:52, 0 users, load average: 27.64, 29.52, 26.68

夜勤さん。
あのね、これ以上転送量が増えたら（っていうか、たぶん増える）いろんな事業化で
ペイする見込みなんて、ますます減ると思うのだけど、どう？
それとも、それくらいはひろゆきも折り込み済かな？

# いまさらこんなこと訊いてしまう気持ちなの。ごめんね。

ｶﾞｲｽﾂかもしれんけどレス数と既得数が同じならｱｸｾｽしないっちゅう機能入れれば
ちっとは負担減る気がするよ。

レス数ってsubject.txt以外で知る方法ってありましたっけ？dat直読みでもわからないですよね？

わたしの考えは、このあたりにあるです。
http://pc.2ch.net/test/read.cgi/software/1016799543/285

おっかけっこが　今はじまったばかりですから
あきらめるのは、まだまだ早すぎでしょ。
去年までは、追っかけてすらいなかったんですから。

>>261
スレをちゃんと読んで書き込みましょう。

◆JOKESIZE :02/03/24 21:30 (日) ID:???
>>夜勤さんありがとうです。
じゃあ、「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
を批判要望で立てて、議論を始めようかと思いますが、どうでしょうか？
そうすれば、告知や課金などの問題はそっちで切り離してやれますし、
このスレは技術論に絞って出来ますので。どうしましょうか？

まー2chの負荷増加は日本のBB化が順調に進んでることの現れってことだな。

夜勤さん、ここの話は
１）全く実現可能性を考慮しないブレーンストーミング的アイデアだし
２）現状をふまえた上で、改良あるいは対策を考える
３）緊急事態の部分を、えいやっと片づける力業

の、どのルートでお話を進めたいのでしょうか？

ななむすさん
ｹｲｴｲの話はあっち、、、とかいうとなんか縦割り行政のようなんですけど(笑)
そんな感じでどうでしょうか？

UpTime(choco) = 7:47am up 8 days, 13 min, 0 users, load average: 0.64, 0.81, 0.92
UpTime(vip) = 7:49am up 23 days, 9:55, 0 users, load average: 10.74, 12.80, 51.10
UpTime(love) = 7:47am up 33 days, 21:03, 0 users, load average: 19.28, 20.45, 22.69

>>264
言い方が演技チックですな。がんがってください

1 + 2 + 3 と欲張ってみる。

私にもどうして良いかわからないのだー

>>264
あきらめはしないですよ。むしろ、そんなに急いで追っかけなくてもな、って。
途中で息切れしちゃうかもですよ。

>>265
読んでますですよ。ごめんね。

>>レス数ってsubject.txt以外で知る方法ってありましたっけ？dat直読みでもわからないですよね？

DAT直読みなら行数で分かるぞ

１）HTMLとツールでサーバを分けてみる
２）datとかその辺要求するようなものは別のデーモンで出してみる
　(Big-serverがうたっている、通常のサーバ運用とは異質のサービスなので)
３）過去ログ等は過去ログサーバに一括して集約し、現在アクティブなスレッドは
　一切検索ロボットを受け入れない。
４）subject.txtとdatは特殊なディレクトリに置き、monazilla関係のツール
　以外からはアクセスできないような形にする
５）subject.txtを使った更新チェックのみを認め、巡回チェックは
　●購入者にしか認めない
６）アクセス数とサーバ負荷を逆手にとって、
　「こんな負荷にも耐える我が社のサーバ」
　みたいなタイアップを企業と考える（妄想）
７）赤羽にサーバ基地を作る（妄想）
８）人件費はボランティアで何とかして、とにかくチープに何とかする（妄想）

とりあえず、別スレに書いたんだけど、こっちにも張り直し

いまってread.cgiでgzip圧縮せずに、mod_gzipで圧縮ですよね
mod_gzipって、テンポラリファイル作る(はず)だから、(たとえインメモリで処理する設定でも)
どうせread.cgi起動してるんだから、ぜんぶそっちで圧縮しちゃったほうがいいとおもう
ローカルで実験したところでは、mod_gzipのテンポラリファイル作成で、かなりの負荷が
かかっていた

もし、メモリ使用量が気になるなら、もともとread.cgiは、スタティックにzlibライブラリを
リンクしてるとおもったけど、OSに付いてくるzlibライブラリ(もしなければzlibライブラリをインストール)して
shared objectのzlib使えばread.cgiのメモリ使用量も抑えられる

掲示板をどんどん増やしているのが原因な気がするんですけど。
増やすことで人数の分散を図っているとしたら、効果が出ているのでしょうか？

とりあえず、今日を何とかしないと明日はないとおもわれ。あさってはそれこそ・・・。

>>275
そへんは、実況板の歴史を最初から知っている人たちが詳しいです。

２ｃｈ専用ツールの要求って、Big-Serverがいっている
「２ちゃんねるでも耐えられるサーバ提供」ていうのと、ちょっと違うと思うんです。
要するに、常識的にはWebはieやNNのような「ブラウザ」を相手にしているわけでして、
専用ツールによるdat直読み、というのは、普通のサーバの要求仕様じゃない。

何らかの専用デーモンを立てて、そっちでやりとりしてもらえれば、
かなり交通整理が尽くし、何より、Apacheというリソース食いまくりで
メモリ使いまくりなプロセスと縁が切れれば・・・という妄想が常にあります。

そへん

>>267
わかるのですが、向こうのスレに何が要求されてるのか、いまいちわからんのですよ。

>>273 知りたいこと
１）httpd的、対Monazilla daemon が he.net で走る可能性
２）同上
３）検索ロボットとその他の切り分け
４）不可能に思える（●付きなら別）
５）同上（可能な気もする。まだ対負荷考え中）
６）うんうん
７）うんうんうん
８）いくらでも手伝うよー

＞かなり交通整理が尽くし、何より、Apacheというリソース食いまくりで
＞メモリ使いまくりなプロセスと縁が切れれば・・・という妄想が常にあります。

そうなんですか？Apacheってリソース食わなくて軽いって聞いてたんで
意外な話です。

1時までの分のグラフをUPしました。
http://mappy.mobileboat.net/~seek/up/index.cgi
No.803です。

>>281
２ｃｈ専用ツールって、専用ツールなんですから(笑)
専用デーモンで、もう目的ズバリの手順だけを行うデーモンがあれば、
Apacheなどとは比べものにならないほど交通整理できますよ。

UpTime(choco) = 8:08am up 8 days, 33 min, 0 users, load average: 0.69, 0.73, 0.89
UpTime(vip) = 8:09am up 23 days, 10:15, 0 users, load average: 4.26, 5.90, 18.52
UpTime(love) = 8:08am up 33 days, 21:23, 0 users, load average: 12.68, 17.60, 18.65

>>282
鯖ごとに、Usr/Sys/Waitの3系列グラフにして欲しいです。

>>283
むしろApacheとLinuxのソースいじく(以下略

>>283
そうなるとUNIX板かプログラム板の人に頼むことになりますね。

khttpdとか使えないのかな？

http://www6.ocn.ne.jp/~boyakkie/graph1.png
http://www6.ocn.ne.jp/~boyakkie/graph2.png

>>287
このスレの人たちだけでできる・・・んだよね？(汗

>>290
実現可能性を考えてないです。
でも、本当に必要だと思っている人が多かったら出来ますよ。

データ系のデーモンって、PostgresのようなDBもののソースとか
いろいろ参考になるものも多くありますし。
そんなことより、現状を真剣に考えるとすると
bbs.cgiをＣでかく
とか、
もっともっとbbs.cgiを最適化する
とか、
read.cgiもこの際もっと最適化する
なんてのも、つい考えてしまいます。

>>283
セキュリティ上いろんな意味で厳しいと思われ

UpTime(choco) = 8:21am up 8 days, 46 min, 0 users, load average: 0.66, 0.71, 0.80
UpTime(vip) = 8:22am up 23 days, 10:28, 0 users, load average: 5.93, 5.74, 11.40
UpTime(love) = 8:21am up 33 days, 21:36, 0 users, load average: 10.79, 13.54, 15.79

>>291
やる人は実際のところ、いると思うー。
だけど、それを許してくれる土壌がここにあるかどうか。

現状だって、「最適化したってどうせ使ってもらえないよ」って思うから、
read.cgiもいじくられていないわけで。
bbs.cgiなんてもっとだめだろうし。。。

手抜き、ただ並べただけ。
http://www6.ocn.ne.jp/~boyakkie/average.html

ところでスレ単位で件数を保存(subject.txtを分割したようなの)って
出来ないんでしょうか？分割すれば更新チェックはそのスレへの件数
チェックのみで済んで負荷が減る気もするのですが…

アクセス数とかどうので逆に負荷増えるかも…

从#~∀~#从＜はしのちゃん、失敗やね。

>>296
反対に負荷高くなると思います私も。

从#~∀~#从＜誤爆や。堪忍してや。

>>296
今もheadリクエストで済ませているのではなく？

>>294
環境が整ってないよね。
ソースががどこで公開されてるかわからない。
板の仕様がわからない。
どこにパッチを投げたらいいかわからない。

この状況を変えれば、協力者は必ず現れる。

>>298
>>300
素人考えですので…
ただ思いついただけです…

>>301
賛成。Monazilla.orgできちんと仕様書作って公開した方がいい。
え？作るのはMonazilla賛同者ですよ。あたしゃ知りません。

直近の話だけであれば

「subject.txt以外の更新チェックは禁止」
「rawモードによる更新チェックは禁止」
「datの中身自体での更新チェックは禁止」
というのと、併せて、何らかの「datにさわれるツールの限定」
を行って、無意味にアクセス数が増えることを抑止するというのが理想だと思います。
また、可能であればbbs.cgiをmod_perlにするとか、PHPにするとか、
もっと軽い内容に書き換えるとか、そういう努力もしてみるべきかと思います。

UpTime(choco) = 8:43am up 8 days, 1:09, 0 users, load average: 0.37, 0.57, 0.65
UpTime(vip) = 8:45am up 23 days, 10:51, 0 users, load average: 4.29, 4.12, 5.93
UpTime(love) = 8:43am up 33 days, 21:59, 0 users, load average: 10.18, 10.85, 12.72

http://pc.2ch.net/test/read.cgi/software/1016799543/740
みたんだけど、
.htaccessを読むのは、アクセスごとなので、結構負荷がかかる

.htaccessを読まないようにして、

たとえば、特定のディレクトリだけの設定をするのなら、
<Location>や<Directory>を使用すべき

また、たとえ.htaccessファイルがなくても、アクセスごとに探すので負荷が高い

普通の設定だと、
/aaa/bbb/ccc/ddd/eee/fff.dat にアクセスすれば、
アクセスごとに、
/.htaccess
/aaa/.htaccess
・・・・・
/aaa/bbb/ccc/ddd/eee/.htaccess
を全部探すから非常に効率が悪い

httpd.confと別ファイルでするなら、
httpd.confからinclludeで読み込むべき

＞Dreamさん
Apacheは相当最適化されてる
ただし、httpd.confの設定によって、かなり変わる
ハイ・パフォーマンスにチューニングされたhttpd.confをつかったApacheに
勝つのは、khttpdくらい
いまの設定を変えれないなら、
別ポートにチューニングしたhttpd.confのアパッチを立てるのがいいんじゃない

ｓｕｂｊｅｃｔ．ｔｘｔ自体にさわりに行くものも、実際問題として、
専用ツール以外には必要ないので、これも隠しちゃってよいものではないかと思います。
で、monazillaに参加しなくては開発できないものとしたらどうかと思います。

>>306
の件ですが、夜勤さん、httpd.confを編集することは、可能なのでしょうか？

>>306さん
具体的にどのくらいのオーバーヘッドになるのか、目安が出せませんか？
出せませんよねぇ・・・・何かの例でもいいんですけど。

>>304
そのためには、鯖に新たなcgi/daemonが必要と思いますが、あってる？

>>306
全般にわたって同感。

UpTime(choco) = 8:52am up 8 days, 1:17, 0 users, load average: 0.54, 0.58, 0.62
UpTime(vip) = 8:53am up 23 days, 10:59, 0 users, load average: 4.32, 4.22, 5.22
UpTime(love) = 8:52am up 33 days, 22:07, 0 users, load average: 9.57, 10.27, 11.67

>>308
apacheのソース読むと感触がわかると思います。。。
ただ、単純にファイルオープンが増えているわけで。

>>307
＞＞で、monazillaに参加しなくては開発できないものとしたらどうかと思います。
これはだめです。
確かに理想としてはいいのかもしれません。
しかし、囲い込みは反発を招きます（今の規制でも招いています）。

このあたりの決定に際しては、バランスを取ることが必要です。

>>307
>で、monazillaに参加しなくては開発できないものとしたらどうかと思います。

これ本当にいいと考えてますか？
オープンソースの話もそうだけど、仕様を踏まえるかどうかと、
monazilla に参加したりするのは別個に考えた方がいいんじゃ
無いですか？
# 作者の意思が優先すると思う。

>>308
はっきりいいますか?

うちのサーバ(正解にはちょっとちがうけど)である限り
つまり　２ちゃんねるのサーバではない限り、
私は拒否します。

なぜかって? 私のやることが増えるからです。

>>309
いえ、出来れば、Basic認証でも何でもいいので、簡易な形で
やって欲しいところですよね。
非・monazillaツールがここの部分をハックして入ってきたら、
通信法で何とかなりませんですかねぇ？

>>315
>通信法で何とかなりませんですかねぇ？
その意気込みがあるなら可だと思います。
●認証だけではなく、●○共有のMonazilla認証ってことですよね。
>>312-313 的な反対はあると思いますが。。。

>>312-313
だとしたら、datに直にアクセスかけて、巡回をするという高負荷な
システムを、どうやってほかのものと区別をするのか、
アドバイスをお願いします。

>>314
了解です。

そもそも、直にdatを触って更新することに、どんな意義があるのか、
もしこの機能を養護される方が居られましたら、お聞かせ下さい。

１）ダイアルアップや従量制でネットを使っている人が、経済的に
　　いっぺんにdat取得して、オフラインで読みたい

というのは了解です。
その通りだろうし・・・
その上で、そういう人たちに●購入していただく、というのは、だめなんでしょうか？
という気も・・・・・・

>>318
技術的な問題でなく、心情的（政治的？）問題だと思うですよ。
「登録しないといいツール作れないのか。２ちゃんも変わったなー。」的な。

すいません、質問させてください。
ブラウザを使うのと、専用ツールを使うのとでは、
どちらが高負荷かつ高転送量なんでしょうか？

私自身がブラウザ派なので、2chではどういう認識なのか知りたいのですが。

＃関係ないなら無視してください。

カード持ってないってのが辛いです

>>319
わかりますけどね。
攻撃がない平和なところだったり、アクセスでサーバが悲鳴を上げていなかったり、
回線帯域が潤沢だったりすれば、そのような牧歌的なところでよいのでしょうけど。
少なくとも、なにか暗中模索したいと思ったら、何らかのルールは必要になるような
気がするのです。

>>318
monazillaツールの作者の立場を抜きに考えてません？

2ch側が作者に金出して「作らせてやってる」ならともかく、
そんな事言うんなら、自分で作れって言われると思いますよ。

かちゅの作者を見ても判るように、いつ作るのを止めてもいい
のがフリーウェア作者の立場であって、それを無視して話すの
は、すごい失礼だと思う。

>>319
その通りです。
プログラマは、仕様がオープンであることを好みます。
クローズな仕様だとしても、調べ上げてオープンにしてしまいます。

プログラマは孤独な性格が多いので、参加を好まない人もいるのです。

ツールのユーザーや管理者にはどうでもいい話かもしれませんが、
こういう人間もいるのだということを知って欲しいです。

何か話が飛んでるような気がします。

subject.txtを読むのと、
subject.txt読んで更新チェックするのと、
dat直読みの巡回をするのと、
dat直読みでスレッド取得するのと、

今は何の話をしているんですか？

>>323-324
感情論はよくわかりますし、実際問題、大変な作業を全く見返りを
求めずやってるのだ、ということは理解しているつもりです。

その反駁は、ですからよくわかるのですけれど、
「だったら、この現状をどうするんだ」
という視点からの発言もお願いしたいのです。
そういう場所ですから。

read.cgi呼び出しのチェックの話。

単純に、たとえば１分以内の再呼び出しを弾くためには、１分間分のアクセスリストを
保持して、そのファイルをオープンして検索かけるわけですが、これは鯖単位とすると。。

１分間の呼び出し分だけファイルオープン数が増える（read）。
その何分の１かファイルオープン数が増える（write）。
わけで、高負荷なときはすさまじく重くなり、低負荷の時はあんまり意味のない機能かと。

夜勤さんが言ってらしたのですが
「回線帯域も、サーバも、予算が潤沢にあればすぐにも解決」
する問題ですよね？実際。

そういう解決法ではない解決法として、じゃあ、monazillaとかそのような
比較的意志の疎通がとりやすい緩い結束
(なのかどうか、私自身は加わっていないのでわかりませんけど憶測で)
に、今後のサーバの「転送量とサーバ負荷のトレードオフ」のコントロールを
ゆだねられないとしたら、どのようにしたらよいのかを、ご提案いただきたいのです。

>>326
たぶん、押し切って勝てるかどうかの問題かな。。。
夜勤さんやひろゆきさんたちの趣味の問題でもあるか。

みんな、理解はしていると思いますよ。
ただ、苦労して付いていく人がどれだけいるか、
２ちゃん住民の２ちゃんに対するコミットが変わりやしないか。。。

住民減って大歓迎なら、やっちゃってもいいと思う(笑

>>327
２チャンネル専用プラグインを開発して、push型に更新するというのはどうでしょう（妄想）

>>330
あの前提崩していいなら、ありだと思いますよ。

# でも、それなら P2P型プロジェクトの類の方が良いと思いますが。。。

横やりすまんが、ほんとはツール使われるのイヤなんじゃないの？
そうじゃなかったらこんな規制しないもん。いっそのことツール禁止にすれば？
反発あるかもしれんが、もともとツールなんてなかったんだし。どうよ？

>>331
P2Pのタイムラグとか、解決できるんでしょうかね？
各ユーザ間の回線がどんどん太くなっていったら、あり得る話ですよね。

FTTHとかB-Flets100Mとか使って２ちゃん運営、というような話も誰かしてましたけど。
昔。
(みんな妄想です)

>>332
ツール使われるのがいやだ、というより、
帯域使用料やサーバの慢性的な高負荷に耐えられない、
ということだと思うんですよ・・・
その要因になるものは、何とか排除したいなぁ、というのが今までの流れなのです。

>>333
大幅に仕様変更するなら、P2P的なものの方が未来を見てるかな、と。
いや、なんならＱ２専用のイントラネットで２ちゃん運営とか（ばか

>>332
私が夜勤さんの立場なら、８月からツール全面禁止の方向にしたと思います。。。

# でも、あのときそういうこといったら、とても反発が強かったです。
# 考え無しな発言だったと思います。Monazillaさんたちがんばってるんだもの。

ま、そんなこといってもしょうがないので。

>>336
あれ、そうだったんですか？
ブラウザより転送量が抑えられるので、
ツール使用を推奨していたと思ってましたが…

# サーバに負荷かけてでもgzip導入した、って話聞いたけど

UpTime(choco) = 9:40am up 8 days, 2:05, 0 users, load average: 0.34, 0.45, 0.48
UpTime(vip) = 9:41am up 23 days, 11:47, 0 users, load average: 1.38, 2.03, 2.39
UpTime(love) = 9:39am up 33 days, 22:55, 0 users, load average: 12.02, 9.37, 9.15

今日はこの辺で、おしまい
明日移行は game サーバも一緒にとります。
数日してから game サーバにも導入してみましょう。

やっと過去ログ読んだけど、議論がループしてるような気がする^^;
どっかで聞いたことがある話がチラホラ・・・

思い切って、全ユーザー課金にしたら？
月１００円とかなら出すよ。

私が夜勤さんなら、逆に、ブラウザ完全禁止にして、cgiからhtml吐かせる
部分を完全に削っちゃうけどな。というか、ユーザのPCに表示部を任せて
鯖側はデータのみの方が、転送量＆負荷的に有利だと思うが。

>>337
当初はmod_gzip使わないでやったからMonazillaツールのみgzip効果があった
現在はmod_gzip入っているのでブラウザでも問題なし、ということでは？

>>337
超短期的には、gz圧縮がきかなかったからブラウザが正解。
短期的には、差分取得できるし圧縮もできたからツール使用が正解。
長期的には。。。
（結局はユーザーインタフェースとしてどちらが便利か＝鯖に負荷かけるか、だと）

>>338
ぺこり。

>>340
それ、（･∀･）ｲｲ!
Ｓ／Ｃシステムから考えると一番いいと思うなぁ・・・

bbs.cgiを最適化するというのは、
短期的に考えるといいかも知れないが、
長期的に考えると仕様変更に弱くなって辛いかもとか
思ったり・・・

結局、付け焼き刃じゃダメなんだって！

ツール強制になった時。
それは２ちゃんねる終焉の日。

>>338
お疲れさまでした。

>>343
read.cgi的動作をクライアントに任せるのは、確かに魅力的ですが、、、
read.cgi自体の負荷をもっと削る（特に ressplitter_splitあたり。>> 制御）
前提なら、私は指数級数的なアクセス増大の方が怖いです。。。
Apacheまで手を入れる前提なら、両手を挙げて賛成。

妄想と至急策が混在しててすいません。

read.cgiのみは今後もhtmlで提供するけど、書き込みなどは
ツールじゃないと出来ない、といったのを妄想していました。いま。
意味ないですが。

>>348
書き込みを規制してもあまり意味ないんじゃないの？
実際はROMの方が遙かに多いでしょ？
いや、データを取った訳じゃないから分からんけど。

書き込み規制＝1ch
とか言ってみるテスト（ｗ

>>347
＞Apacheまで手を入れる前提なら

私はやって欲しいけど、なーんの権限も持ってないからなぁ

>338
お疲れ様。

ということで本日の負荷グラフ最終版です。
ttp://mappy.mobileboat.net/~seek/up/index.cgi
No.807です。

鯖にはあまり手を入れないっていうのが前提ですね。
結局鯖に手を入れると夜勤さんの管理負担が大きすぎるので、そうしたいなら他のところで
やって、というのが本音のようなので。

>>352
乙！

>>349-350
うんうん(笑)

>>351
Apacheに手を入れるのって、具体的にどんなヒントがあるんでしょう？

やはり、政略的な面から言わせてもらうと、
直ちに雑誌掲載禁止の措置を取るべきだと思う。
ネトランとかはマジで悪質だぞ。

なあ、技術的な話題に変えたつもりかもしれないが
やっぱり場違いくんだよ。話が見えていないんじゃないか。>>351
不確定な前提で話しすぎていて無駄だらけ。頼むからROMっててくれないか？

>>356
さんせ〜い。

>>358
いますぐやろうよ（ｗ

>>359
作った人間が決める事

夜勤もいねーし一言。
管理者側からすっと「お客さんﾏﾝｾｰ」なわけだ。
でもこの２ちゃんは大きくなりすぎちゃって、
サイトを開く家（場所）がないと・・・。
確かに鯖いっぱい借りて分散すればいいわけだが、
それには金がかかる。
そこら辺の問題が一番なんでしょ？違うかったらｺﾞﾒｿ

>358
ありゃまだいたし（ｗ

何気に動揺・・・ageてｽﾏｿ・・・（鬱

>>361
３ちゃんを作って分散を・・・
って兄とかいちごとか色々あるね（ｗ

>>357じゃないけど、AJA6H/Ws ◆MPnX7dHAは発言がズレてると思う・・・

>364
ﾚﾝﾀﾙ借りて思う事。
「持ち主から苦情来たらどうすんべ・・・」
で、実際今そーいった問題が来てるわけだ。
転送量とかってのね。
いくら圧縮かけたり、巡回禁止しても、
これだけ２ちゃんが大きくなったら対応するのは難しいと思う。
課金ってのは好きじゃないけど、
今の現状考えたらいたしかたなし・・・ってとこかな。

>>366
まぁ、私は８月から覚悟してましたので・・・
規制がかかるくらいなら、課金を選びますね。

ただ、●にも問題があるからびみょー・・・
メリットなさ過ぎだし、カードでしか支払えない。
せめて、銀行から払えればいいのだけど。
私はカード持ってますけど、一般的には弱いと思う。
禿しくがいしゅつの意見で悪いけど。

>352
お疲れ様です。
http://www6.ocn.ne.jp/~boyakkie/average.html

>367
わかるよ。今のままじゃね・・・。
まぁそれは今後経営者達が考えればいいんじゃね？
俺が今言いたいことは、
こんだけ夜勤とかがんばってるけど、
所詮いたちごっこで、また同じ問題が起きるって事。
まぁそれだけ人気あるからしゃーないけど（ｗ
でもここはちょっと２ちゃんのターニングポイントだね。
１００円や２００円払ったって俺はいいと思う。
それだけ楽しめればね(^^ゞ

>>369
そーそー、bbs.cgiにいくらテコ入れしても結局は耐えられないよ。
そして、最適化で難解になったコードに後でまた苦しめられる二重苦・・・

課金が強制的になれば、月１００円でも
そうとうな収入になると思うのだが。

グッズが出ても買うよ。
私がマガジソかった理由は、単純に
オマケのステッカーが欲しかったという理由だから（ｗ

しかし、商業化すると更に鯖負担が増すという罠（ｗ

>371
そしたらまた考えれ
商業化するならそれくらいは悩まないとねぇ（ｗ
まぁ無料奉仕の限界って事じゃね？

>>370
bbs.cgi せっかく部分ごとに{}囲んでるのだから、もっともっとnextとかlastとか
駆使してBLOCKオーバーヘッドと変数放り込みループ削るだけでもだいぶ(以下略

>>370
100円じゃおそらく認証等の費用で足が出るんでわ

>>373
bbs.cgiってmod_perl出来たら、どのくらい負荷が軽減すると思います？

>374
100円ってのは根拠のない例えです。
実際何人の人が２ちゃｎ見てるかもわからねーし。
でもそれくらいなら払えるじゃん？
それだけの事（ｗ

>>373
それを　たった今　トオルさんと二人でやっているとこだったりして、

>>377
がんがれ！

>夜勤
がんばって！
俺の言いたいこと言ったんで、
あとは管理者に任せます。
でも２ちゃんのこのみんなで協力ってのはいいよねぇ
影ながら応援しています(^^ゞ

>>375
mod_perlって、コンパイル時にメモリに常駐しちゃう奴だっけ？
実際にこれで動いてるシステムってあるのかなぁ？

>>307
subject.txtを隠すとどこにどんなメリットがあるのかさっぱりわからん。
ていうか隠せるのか？

>>375
実は mod_perl あまりよくわからないのん(ちょっと怖いという印象が)。

>>377
実は昨日ひとり寂しくやりました。
DispError(...) if ...;
系の文章がすごく多くなりましたよ。えぇ(笑

できるだけ複合文使わないよーにね、ってお伝えください。

>>381
一つには、これ使ってクラッカーがランダムにスレッドを目標に設定して
荒らしている、ということがあるようです。
隠せるか？ということでは「やり方はあります」という程度です。
それはBasic認証でツールが直に要求して、という方法もあるし。

＃盗むの簡単、なりすます野簡単だよ？ということになるかも知れませんが、
＃それは通信法の適用範囲になるでしょう。きっと。

>>382
毎回コンパイルしなくなる、という点で、ちょっともしかしたら
劇的な効果があるんじゃないかって思ってるんですけど、
副作用について、私もよくわかりません。

bbs.cgi の負荷軽減と　gzip 圧縮の話しだけど、
今は　bbs.cgi で書き込まれたら
gzip を　peral から二回呼び出しているのよね

CAll gzip index.html
CAll gzip subback.html
subject.txt は、　mod_gzip の方でやっている

でこれを　index.html subback.html subject.txt を一気に
index.html.gz subback.html.gz subject.txt.gz にするスクリプトを C で書いて
bbs.cgi からは一発で呼び出したら、軽くなるかな?

>>384
bbs.cgiをC言語で書くというのはがいしゅつ？
どっかにCGI用のライブラリとか転がってないかな？

>383
subject隠したらsubbackを読むようになるだけだから
転送量が増える分だけ２ちゃんねる側の損じゃん。

あ、微妙に夜勤★さんとｶﾌﾞﾀ（ｗ

>>384
その通りで、効果があるとは思うのですが、いい噂を聞かないというか、何というか。。。
（とりあえず夜勤さんマターだからおまかせ、ってこともあり）

>>386
C で書いてもいいんですけどね、
ただ　規制とかの機動性がなくなっちゃうんですよね
いろいろな人が臨機応変に触れなくなるという罠。

>>387
むずかしいもんですねぇ。。。

>>390
なるほど。

>>391
同感・・・

>>385
軽くなると思いますー。
。。。でも微妙かも。なんかオーバーヘッドが気になる。

>>386 >>390
やりたいですね(笑
いつも、さっぱりきっぱりトオルさんに遠慮されてしまいます。
>>387
！

>>385
ソースを見ていないので私にはbbs.cgiのことはわからないのですが、
cgi内部からあえて子プロセス使うのは、どうかなって思います。
(実際は、Ｃコードがどれだけ最適化・効率化されているのか？といった点で変わると思います)

gzip + gzip + mod_gzip
->
子プロセス + zlib*3

やっぱり、確実に早くはなると思うが、、、といったとこかな。

main()
{
char bbs[] ; // command line から 板名をとる
/*bbs を　test/ からの相対パスにする (../bbs)*/
zz_gzip(bbs,"index.html","index.html.gz");
zz_gzip(bbs,"subback.html","subback.html.gz");
zz_gzip(bbs,"subject.txt","subject.txt.gz");
}

で動くコード誰か書いてー
実験すね価値はあるような予感。

>>393
軽くなりますかねぇ？
Perlのルーチン効率化して、その上で、サーバの負荷的な面で考えてどうなんでしょう？

>>396
そうですね。やっぱり試してみないとわからないところです。

夜勤さん、トオルさん的には、もうsubject.txtは
隠す必要はなくなったのでしょうか？
＞クラッキング対策としての要望というか。

攻撃受けたときの事を考えると
隠したいですけど　>>399

subject隠したらsubback・・・

>>395
ファイルオープンの負荷とかわすれてた。。。

なーんか
http://www.hoops.ne.jp/~yk2yk2/mn/perl/gzipctl.pl
こういう方向性を考えてしまう。

# せっかく index.html も subback.html も subject.txt も bbs.cgi が
# 内部生成してるんだから、ストリーム的に圧縮した方が、と。

めんどくささの問題と変更しても良いかどうかの問題で

subject.txt は形式、名前かえたら　大変なことになるけど、

subback.html は、名前変えようが、中身変えようが
自由自在なわけで、

>>402
うん。そう思うところはあります。
Ｃで呼び出すと、Ｃが子プロセスになって、その孫プロセスで圧縮するわけですよね？
しかも、データを標準出力で受け渡して。
だったら、Perl内部で完結した方が、負荷は少ないような気がします。

>>404
両方作ってテスト、ですかね。。。。

subbackは変幻自在なノカー！

なんか雪降ってるですか。。。
除雪車が動き回っているぞー

>>405
そうしないとわかんないですね(笑)
プロセスプロセスいっても、一瞬で終わるかも知れないし。

sub do_gzipとか作って、
&do_gzip("$data");
とかでルーチン内でやっちゃうっていうのは、けっこうPerlではよくある話なんですけど。

札幌は降ってるノカー？
北見は降ってないじゃないカー。

現状を報告しますと

index.html , subback.html は bbs.cgi 内で
投稿があるたびに以下が行われるです。

system("gzip -c $INDEXFILE > $INDEXGZFILE");
system("gzip -c $SUBFILE > $SUBGZFILE");

subject.txt は、クライアントからリクエストされるたびに
mod_gzip が動いているはず。

>>382
ななむすさんって、bbs.cgi見られる人だったのですか？

#include <stdio.h>
#include <sys/mman.h>
#include <zlib.h>
#ifndef MAP_FAILED
#define MAP_FAILED (void *)(-1)
#endif
#define COMPRESS_FLAG "wb6" /* wb1-wb9 */
void compress_one(const char *fname)
{
　int fd;
　void *buf;
　int fd = open(fname, O_RDONLY);
　if (fd >= 0) {
　　struct stat st;
　　if (fstat(fd, &st) == 0) {
　　　buf = (char *)mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
　　　if (buf != MAP_FAILED) {
　　　　char gzname[256];
　　　　sprintf(gzname, "%s.gz", fname);
　　　　gzFile file = gzopen(gzname, COMPRESS_FLAG);
　　　　if (file) {
　　　　　gzwrite(file, buf, st.st_size);
　　　　　gzclose(file);
　　　　}
　　　　munmap(buf, st.st_size);
　　　}
　　}
　　close(fd);
　}
}
void compress(const char *bbs, const char *fname)
{
　char fnbuf[256];
　sprintf(fnbuf, "%200s/%30s", bbs, fname);
　compress_one(fnbuf);
}
int main(int ac, char **av)
{
　if (++av, --ac) {
　　compress(*av, "index.html");
　　compress(*av, "subback.html");
　　compress(*av, "subject.txt");
　}
　return 0;
}

新聞見てニ速＋へ。社会から遠くにいた今日一日だったのだなぁ。。。

>>410
少なくとも $INDEXFILE 作成 → $INDEXFILE open → $INDEXGZFILE
よりは、$INDEXGZFILE も $INDEXFILE と同時に作る方法が軽いと思います。

。。。が、今日は寝るです。仕事どうしよう。寝れるのかなヽ（´ー｀）ﾉ
皆さんお疲れさまでした。

>>411
見られないですよー。
こちらからはいくらでも公開しちゃうのだけど(笑
４種くらい手持ちのを見つつ、想像しつつ、です。

>>413
お休みなさいです〜

ちょっと見ただけでも
　sprintf(fnbuf, "%.200s/%.30s", bbs, fname);
とか、ぼろぼろだ

>>412
!! お疲れさまですです。

>>413
乙〜〜！

>>410
system("gzip -c $INDEXFILE > $INDEXGZFILE");
と
`gzip -c $INDEXFILE > $INDEXGZFILE"`;
と、どちらが負荷が少ないのかなぁ？と思いましたが、どちらも大して違わないかも知れません。
さらにいいますと、その内容であれば、Ｃで別プロセスに任せるより、そのままの方がよいと思います。

kage.exe　Version０．９９．１．６に。

sub do_gzip [ `gzip -c $_[0] > $_[1]`; }
として、&do_gzip("$INDEXFILE","$INDEXGZFILE");
等という呼び出し方をすれば、若干スクリプトが効率化するかも知れませんね。

余談ですいませんでした。

おお。かちゅ〜しゃの巡回ボタンが更新チェックになっとる。

動作確認した。圧縮率は外からも指定可。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <ctype.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <zlib.h>
#ifndef MAP_FAILED
#define MAP_FAILED (void *)(-1)
#endif
char compress_flag[30];
void compress_one(const char *fname)
{
　int fd;
　void *buf;
　fd = open(fname, O_RDONLY);
　if (fd >= 0) {
　　struct stat st;
　　if (fstat(fd, &st) == 0) {
　　　buf = (char *)mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
　　　if (buf != MAP_FAILED) {
　　　　char gzname[256];
　　　　gzFile file;
　　　　sprintf(gzname, "%s.gz", fname);
　　　　file = gzopen(gzname, compress_flag);
　　　　if (file) {
　　　　　gzwrite(file, buf, st.st_size);
　　　　　gzclose(file);
　　　　}
　　　　munmap(buf, st.st_size);
　　　}
　　}
　　close(fd);
　}
}
void compress_file(const char *bbs, const char *fname)
{
　char fnbuf[256];
　sprintf(fnbuf, "%.200s/%.30s", bbs, fname);
　compress_one(fnbuf);
}
int main(int ac, char **av)
{
　int mode = 6;
　++av, --ac;
　if (ac == 2 && isdigit(*av[1])) {
　　mode = atoi(av[1]);
　　--ac;
　}
　sprintf(compress_flag, "wb%d", mode);
　if (ac == 1) {
　　compress_file(*av, "index.html");
　　compress_file(*av, "subback.html");
　　compress_file(*av, "subject.txt");
　}
　return 0;
}

bbs.cgi内部で圧縮するのが一番いいのは確かだけど
Zlib入ってるのかな？
MD5とかも入ってなくて(^_^;)が苦労してたような。
include/に、zlib.hもなかったし。

何かこんな時間に......乙カレーです．

ところで，こういうの使えばfork()せずに済むかと．
http://cpan.org/modules/by-category/17_Archiving_and_Compression/Compress/Compress-Zlib-1.16.readme
http://cpan.org/modules/by-category/17_Archiving_and_Compression/Compress/Compress-Zlib-1.16.tar.gz

fork()してＣのプログラム使うのなら，daemonizeして非同期実行させた上で，
５秒ぐらい待ってその間に発生した圧縮処理を１つにまとめてしまうのも考えかと．

fd = open(CHKFILE, O_WRONLY|O_CREAT|O_EXCL, 0700);
if (fd == -1) return;
sleep(5);
unlink(CHKFILE);
/* 処理続行 */

>>410
ああ、やっぱりsubject.txtはリクエスト単位のmod_gzip圧縮だったのか。
全スレ 655 はやっぱデマだな。

>>418
>その内容であれば、Ｃで別プロセスに任せるより、そのままの方がよいと思います。

なんで？呼ぶプロセスが3つから1つに減るのに？理由は？

うーん、>>174だけど
>>176 言われてしばらく様子見(怒ってないよ>>177)
>>314に口あんぐり
>>380あたり見て唖然。そんなこともしてないのか。
どうりでこの程度のアクセス数でパンクしそうになるわけだ。
ここの仕組みからすると10倍アクセスが増えても楽々
こなせるよ。

しかし、それ以前にロードが20超えても何もしないで手を
こまねいてる管理がおかしい。全然チューニングすら
してないってことじゃないか。

そんな管理に振り回されるツール作者がまったくもって
気の毒だ。

>>427
今まで出てきた情報からすると
そもそも、2chの鯖は無償で（サーバを使ってもらうことで広告としているが、無償といってもいいだろう）
提供されていること、管理もボランティアで持ち出しになっていることを認識する必要があるかと。
さらに、Big-Server（NT.technology？）とhe.netの保守管理契約上、チューニング等は行いにくいというのが
あるようだ。チューニング等の細かいカスタマイズをするんだったら、he.netは電源とリブートしか責任をも
たないよ、ということになっているのだろう。
2chが相応の金を払っているならともかく、この状況ではあまり強くいえないだろう。

そう、ツールだけになったら敷居が急に上がる。
入りがめんどくさいと参加者も減る、と。

なんでnetnewsじゃなくてWEB掲示板なのか・・・

なぜnetnewsが敬遠されているのかを考えるべきかと（ってスレ違いだﾖ）

>>427
ならお前が無償で管理してやれ

>>426
Cから孫プロセス3つ起動するんだから都合4プロセスになる

>>422のどこで孫プロセス起動してるんだ？

たぶん >>418 とか >>432 とかは
Cの1プロセス内でzlibで処理するという話の流れを読めずに
Cからさらに子プロセスでgzipを呼び出すものと思ったんだろう

現在・・・　kage.exe version 0.99.1.7

ぎこはにゃーんは最新版でread.cgi使わなくなった
A Boneは1.23bで暫定対応した

読めないという問題が残ってるのは
・MapleSyrup
・Hikky
・Gickoブラウザ
いずれも開発終了・中断してるものばかりなので、しょーがないか？

CでApacheのモジュール書いちゃうのが早いと思うんですけどね。

mod_perlにしちゃうと、HTTPDが太っちゃうので、イマイチな気がします。
やるんだったら、Port8080とかで書き込み専用のHTTPDをあげちゃうとか。

>>437
プロクシを通さないと読み書きできない人とかが
普通のブラウザで読み書きするときにも
設定をするときに四苦八苦しそうだね。

>>431
ふむ、煽りにマジレスも収まりが悪いし、まだ言いたいことも
あるんだけど、スレ違いどころか板違いなので、とりあえず
もうやめときますね。

Perlでなら、とりあえずsystem関数でgzip使うより、
Compress::Zlibモジュール使った方が速いみたい

Benchmark: timing 100 iterations of module, system...
　　module: 6 wallclock secs ( 5.89 usr + 0.19 sys = 6.08 CPU)
　　system: 10 wallclock secs ( 0.02 usr 0.06 sys + 8.43 cusr 1.32 csys = 0.00 CPU)
-----------------------------------------------------------
use strict;
use vars qw($file $i $j);
use Benchmark;
use Compress::Zlib;

BEGIN {
binmode(STDIN);
binmode(STDOUT);
$i = 0;# 出力ファイル名を変える必要はないけど
$j = 0;# 念のため

open(TEST, "testfile") or die;# 'testfile' ... 218KB
read(TEST, $file, -s TEST);
close(TEST);
}

timethese(100,{
'module' => q{
my $gz = gzopen("mod_$i.gz", "wb");
my $byteswritten = $gz->gzwrite($file);
$gz->gzclose();
++$i;
},
'system' => q{
system("gzip -c testfile > com_$j.gz");
++$j;
}
});

>>438
べつに8080じゃなくっても10080でも10001でも10000でもいいけどね :-p

>>436
>Gickoブラウザ

Gicko は対応する予定
http://pc.2ch.net/test/read.cgi/win/1004213099/

こういうのがオープンソースが悪いとは、言えなくなる

>>442　そりゃ、かちゅ〜しゃに対する皮肉ですかｗ

とりあえずbbs.cgiをDevel::DProfでプロファイリングしてほしーなー。
推測より計測。プログラミングの原則でしょ。

>>429
妥協策として、ブラウザからはJavaで書いた専用ツールが
起動するようにするのはどうか。
全板じゃなくてHTTP向きでない実況chだけでも。
もちろん操作性と速度を確保しないと実況スレが各板に逃げ出すが。

>>445
ますます負荷増大だぞうだい

>>444
bbs.cgi ってあまり関数に分割されてないから、
Devel::DProf で計測してもあまりデータにならなかったりして。
今のbbs.cgiがきれいなコードになってればいいんだけど。

>>439
本気で板違いだから言いたいことあるならこっちでどうぞ

「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/l50

>>142
>時刻tちょうどに2個のリクエストが来ると負荷は高いけど、
>時刻tに1個、t+0.01秒後に1個来た場合は平坦化されてて負荷は低い、なーんて考え方しちゃってる。

＿＿＿￣−￣−−−−−−−−＿＿＿＿＿＿
　　　　　１　 ２　　　３

HTTPの負荷変動をこんな感じとして
（１＝ｺﾈｸｼｮﾝ確立　２＝ﾘｸｴｽﾄ→ﾚｽﾎﾟﾝｽ　３＝ｵﾌﾞｼﾞｪｸﾄﾎﾞﾃﾞｨ転送）
で、１〜２（0.01秒では終了しない）同士が被るのが一番高負荷、
3同士も出来れば被らないほうがいい
…ここまでは合ってる？

で、今のプログラムだと5個所に１づつ加えるようになってるけど、
もっと@cntを細分化して5個所に上のグラフのようなのを加えればそれは
表現出来ると思うが…


>連続するcnt N個の和の最大値と標準偏差みなよ。

確かにrapidが80前後大きく出たが、それがリクエストの被り具合と言う意味なら
同一クライアントからの（被らない）連続リクエストが被ったものと見なされるので
意味がずれてくるのでは？

今日は　game サーバに導入しようと思っている。
いつも　重重のサーバだからです。
で、導入後　どうなるか、、、

UpTime(game) = 11:22pm up 10 days, 13:52, 0 users, load average: 8.22, 7.75, 7.59

>>436
Hikkyも対応できるようです。
http://pc.2ch.net/test/read.cgi/mobile/1017017560/11

「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」に
やっと、ひろゆき登場
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/388

UpTime(game) = 12:25am up 10 days, 14:56, 0 users, load average: 6.78, 6.89, 7.19

game・・・

ついにgame鯖もMapleで読めなくなるのか…

>>452のURL、踏んでもレス番338に飛べないんだが、なぜだろう？
A Boneだとポップアップは<<レス388は未取得です>>とでる

>>456
388なんて番号は存在しないから。

http://kaba.2ch.net/test/read.cgi/accuse/1016974669/338

338 ：ひろゆ子 ◆HRUNYAXA ：02/03/25 17:11 ID:S7dwYapz
インターバルって単につかいづらいだけなような、、、、
ブラウザでクリックしたほうが早いのであれば、
ツールユーザー自体が減るだけかと、、、

>>457
納得、338じゃん
レスさんきゅー

UpTime(game) = 1:04am up 10 days, 15:35, 0 users, load average: 49.08, 54.73, 29.33

http://kaba.2ch.net/test/read.cgi/accuse/1016974669/374

374 ：ひろゆ子 ◆HRUNYAXA ：02/03/25 18:01 ID:S7dwYapz
既存の機能を有料にするのではなく、
新しい機能を有料で提供したほうが受け入れやすいと、、、
一部のツールでは巡回はついてないので、
巡回が有料になっても受け入れやすいと、、、

ただ、インターバルとか個数とか調整部分の有料化って
あまりうまくいかないだけなような、、、
patchでこせるとか、、

UpTime(game) = 1:09am up 10 days, 15:40, 0 users, load average: 30.06, 35.88, 28.01

UpTime(game) = 1:22am up 10 days, 15:53, 0 users, load average: 19.78, 30.94, 37.58

UpTime(game) = 1:37am up 10 days, 16:08, 0 users, load average: 8.67, 11.78, 22.07

UpTime(game) = 1:43am up 10 days, 16:14, 0 users, load average: 10.15, 10.11, 17.83

UpTime(game) = 1:52am up 10 days, 16:23, 0 users, load average: 10.24, 9.69, 14.31

おいおい…
ひろゆきと考えの差が随分出るもんだ…

[ノォォン！]レンタル鯖から請求３０万！！！
http://pc.2ch.net/test/read.cgi/perl/1016089203/

サイト運営者を貧乏にするbinboserver.comのお申し込みはこちらから
http://www.binboserver.com/

ん？夜勤さんもしかして、手動じゃなくて
自動書き込みのスクリプトで書いてる？

だいたいの　２ちゃんねるの　アクセス推移なんだけど
このグラフのがくっと下がったところを下げないで
そのままつなぐと、雰囲気がわかるとおもうです。

http://uptime.netcraft.com/up/graph?site=mentai.2ch.net&mode_u=on&mode_w=on&avg_days=30&submit=Redisplay+Graph

こんばんは。
423 名前：心得をよく読みましょう 投稿日：2002/03/25(月) 18:49 ID:adyfkZPq
>>422
うん。
html:5264195

read.cgi:6114543
bbs.cgi:449721

.dat:3449724
.dat.gz:66991

txt:706191

all:16051365

こんなかんじです。
これ見てて思ったのですけど、単純な発想ですと、
過去ログをどこか別のサーバに移せれば、1/3のリクエストが軽減するんですねぇ。
(妄想)

>470
増え続けてるってこと？

>>471
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/423
です。

html は　index.html , subback.html じゃないかな、ほとんど。

>>472
もちろん、
特に先週あたりからの増加はすごいぞ。
ねずみもまっつぁおー

UpTime(game) = 2:06am up 10 days, 16:37, 0 users, load average: 8.17, 10.26, 12.01

たとえば、love&curry はなんで、こんなに?
http://uptime.netcraft.com/up/graph?site=love.2ch.net&mode_u=on&mode_w=on&avg_days=30&submit=Redisplay+Graph

UpTime(game) = 2:15am up 10 days, 16:46, 0 users, load average: 8.19, 8.41, 10.28

夜勤さんgccとzlib使える環境は持ってるわけだから、Compress::Zlib モジュールを
コンパイルして、どこか書き込み権限持ってる適当な場所にインストールしたらどうでしょうか。

bbs.cgi の中で

use lib "/home/yakin/lib/perl"; # Compress::Zlib モジュールを置いた場所を指定
use Compress::Zlib;

とすれば、perlプロセス内でgzipできます。>>440 あたりが参考に
外部プロセスを呼ぶよりも負荷は明らかに低いから、是非やった方がいいと思います。

>>477
http://uptime.netcraft.com/up/graph?site=www.yahoo.co.jp&mode_u=on&mode_w=on&avg_days=360&submit=Redisplay+Graph
yahoo.co.jpとか・・・・

>>474
ああなるほど、そうですか〜。そうですよね・・・

UpTime(game) = 2:25am up 10 days, 16:56, 0 users, load average: 7.07, 7.85, 9.12

*.htmlって現状では"Last-Modified"を吐き出してませんが，
これは恐らく*.htmlが"server-parsed"になっているためだと
思うのですが，SSIを使う必要がなければこれをoffにすれば
Apacheが余計なparseをせずに済むようになって負荷が減るのと，
"Last-Modified"を吐くのでブラウザ側でのキャッシュが効くように
なると思うのですが．

ところで，>>422を改造して，daemonizeして非同期実行させた上で，
５秒ぐらい待ってその間に発生した圧縮処理を１つにまとめてしまうというの
書いたんですが，bbs.cgi内部でindex.html等のロックをどうやっているかが
わからないとmmap()したところを読み出す時に死ぬかも......

UpTime(game) = 2:35am up 10 days, 17:06, 0 users, load average: 8.97, 8.02, 8.57

UpTime(game) = 2:49am up 10 days, 17:20, 0 users, load average: 7.24, 7.72, 8.10

あ、>>440 を参考になんて書いちゃったけど、実際にはメモリ上のイメージから
非圧縮形式と圧縮形式で書き出さないと無駄なアクセス発生しちゃいますんで。
↓イメージとしてこんな感じで

use Compress::Zlib;

my $subjectContent = 'hogehoge' x 1000;

open(FILE,">subject.txt");
print FILE $subjectContent;
close(FILE);

open(FILE,">subject.txt.gz");
print FILE Compress::Zlib::memGzip($subjectContent);
close(FILE);

UpTime(game) = 3:04am up 10 days, 17:34, 0 users, load average: 147.13, 62.36, 28.20

UpTime(game) = 3:13am up 10 days, 17:44, 0 users, load average: 95.67, 49.60, 34.22

UpTime(game) = 3:27am up 10 days, 17:58, 0 users, load average: 13.45, 21.31, 28.04

UpTime(game) = 3:31am up 10 days, 18:02, 0 users, load average: 8.56, 8.68, 9.10

u-o

UpTime(game) = 3:32am up 10 days, 18:03, 0 users, load average: 52.34, 26.67, 27.43

robutって･･･（´д｀;）

gameｵﾓｰ。。。

スタンド攻撃を受けている？

UpTime(game) = 3:41am up 10 days, 18:11, 0 users, load average: 35.05, 30.62, 30.99

UpTime(game) = 3:43am up 10 days, 18:14, 0 users, load average: 152.67, 76.56, 47.86

ところで、これ書いていってどうするんすか？＞夜勤さん

>>498
http://pc.2ch.net/test/read.cgi/software/1016799543/869

ひとり千争

なんか分刻みでload averageがえらく違うんですが。。。　

他でやれ

UpTime(game) = 3:50am up 10 days, 18:20, 0 users, load average: 36.03, 57.29, 50.66

150って凄まじい数字だな。
処理待ちになってるプロセスが150個あるってことでしょ?
つまり、処理できる能力の150倍のリクエストが来てるわけだよね。

>>504ﾊｧ?

UpTime(game) = 3:56am up 10 days, 18:27, 0 users, load average: 29.57, 32.01, 40.63

それでは、そろそろ　game サーバも変更します。

重くて　作業ができない・・・
一旦　bbs.cgi とめます。

>>507
告知してきます。

Benchmark: timing 100 iterations of mem, module...
　　　 mem: 8 wallclock secs ( 7.85 usr + 0.25 sys = 8.10 CPU)
　　module: 9 wallclock secs ( 8.36 usr + 0.22 sys = 8.58 CPU)

(略)

timethese(100,{
'mem' => q{
open(TEST, ">mem_$k.gz") or die;
print TEST Compress::Zlib::memGzip($file);;
close(TEST);
++$k;
},
'module' => q{
my $gz = gzopen("mod_$i.gz", "wb");
my $byteswritten = $gz->gzwrite($file);
$gz->gzclose();
++$i;
}

});

>505ﾊｧ?

game での作業完了。

Benchmark: timing 1000 iterations of mem, module...
mem: 80 wallclock secs (78.24 usr + 1.93 sys = 80.17 CPU)
module: 59 wallclock secs (57.48 usr + 1.10 sys = 58.58 CPU)

UpTime(game) = 4:14am up 10 days, 18:45, 0 users, load average: 100.07, 78.80, 61.01

The uptime utility displays the current time, the length of time the system has been up,
the number of users, and the load average of the system over the last 1, 5, and 15 minutes.

つまり、実行中のジョブの個数がload、アヴェレージは直近１分、５分と15分のものの平均値を
表示している。

UpTime(game) = 4:20am up 10 days, 18:50, 0 users, load average: 69.10, 64.96, 60.07

>>514
嘘ついちゃだめだよ。「実行中のジョブの個数」ってなんだそりゃ。

UpTime(game) = 4:25am up 10 days, 18:56, 0 users, load average: 24.08, 39.64, 51.18

>>514
「実行可能状態にあるジョブ」ですね。。。

>>516
こまかい語句で揚げ足とるんだったら
http://www2s.biglobe.ne.jp/~hig/q_a/Unix_QA01.html#Q13
ここでも読んでサマリーかいてくれ。

>>518
さんくす。

ツールに対してしか使えないですけどdat落ちした過去ログを参照するときに
キャッシュに強い proxy を自動的に通すことはできないでしょうかね？
どれぐらい効果があるか分からないけど。

UpTime(game) = 4:30am up 10 days, 19:01, 0 users, load average: 17.99, 26.00, 42.58

>>512

自分の環境でも mem の方が遅くなるな。

Benchmark: timing 100 iterations of mem, module...
mem: 43 wallclock secs (42.64 usr + 0.45 sys = 43.09 CPU) @ 2.32/s (n=100)
module: 24 wallclock secs (24.28 usr + 0.31 sys = 24.59 CPU) @ 4.07/s (n=100)

てことで圧縮形式で出力する時は gzopen/gzwrite 使ってね＞夜勤さん

>>522
トオルさんに教えてあげると、組み込まれるのが早いぞー
qb の jikken だったっけ、やってる板。

UpTime(game) = 4:35am up 10 days, 19:05, 0 users, load average: 20.77, 23.95, 37.35

game鯖　作業開始までの負荷推移グラフage。
ttp://mappy.mobileboat.net/~seek/up/index.cgi
No.818です。

>>523
http://qb.2ch.net/jikken/

ベンチマークとるたびに結果が変わるので、何とも言えないが
Compress::Zlibの効果は微妙？
(普通に使えば遅くはならないけど、劇的な効果は望めそうもない)

Benchmark: timing 1000 iterations of mem, module, system...
　　　 mem: 97 wallclock secs (94.47 usr + 2.34 sys = 96.81 CPU)
　　module: 77 wallclock secs (74.29 usr + 2.50 sys = 76.79 CPU)
　　system: 89 wallclock secs ( 0.17 usr 0.65 sys + 76.09 cusr 11.44 csys = 0.00 CPU)

load averageもいいけど、
システムの状態がよくわかるように、vmstat貼ってほしい
loadavgだけでは、システムの状態がつかめない

% vmstat 5
とか
% vmstat 60
とかやって、まとめて貼るとかはだめなんですか

biwa35:~$ vmstat 5
procs memory swap io system cpu
r b w swpd free buff si so bi bo in cs us sy id
3 0 0 0 32836 175116 0 0 7 4 13 15 8 14 9
1 0 0 0 40284 175116 0 0 64 70 1238 1837 79 21 0
7 0 0 0 37480 175116 0 0 40 24 1381 2079 76 24 0
4 0 0 0 44956 175116 0 0 169 99 1448 2083 72 28 0
5 0 0 0 40096 175116 0 0 25 374 1577 2308 72 28 0
1 1 0 0 43928 175116 0 0 36 59 1355 1909 74 26 0
7 2 0 0 22336 175116 0 0 166 453 1700 30029 66 34 0
10 0 0 0 17304 175116 0 0 67 452 1618 2096 65 35 0

続く。。。

4 0 0 0 7280 170004 0 0 116 403 1567 8150 68 32 0
7 1 0 0 3592 150532 0 0 73 504 1661 2438 65 35 0
0 1 0 0 10068 147896 0 0 47 674 1690 13880 68 32 0
10 0 0 0 7596 140624 0 0 140 498 1631 52737 61 39 0
14 2 0 0 11620 127952 0 0 241 744 1881 3155 60 40 0
9 0 0 0 27136 125724 0 0 178 324 1710 4372 64 36 0
0 1 0 0 33208 125724 0 0 77 633 1630 23248 66 34 0
4 0 0 0 30008 125724 0 0 98 585 1809 2972 67 33 0
0 0 0 0 35032 125724 0 0 58 434 1744 6085 71 29 0
2 1 0 0 260820 125724 0 0 133 282 1501 2009 65 35 0
0 0 0 0 390880 125724 0 0 39 400 1329 23170 80 20 0
1 1 0 0 342908 125724 0 0 17 9 898 739 84 16 0
1 0 0 0 300228 125724 0 0 76 151 1026 1081 83 17 0
4 0 0 0 255480 125724 0 0 130 27 1158 1123 77 23 0
7 1 0 0 225284 125724 0 0 209 212 1459 2023 72 28 0
4 0 0 0 192356 125724 0 0 28 190 1200 3723 75 25 0

UpTime(game) = 4:43am up 10 days, 19:14, 0 users, load average: 18.18, 21.42, 30.39

vmstat の説明
http://www.linux.or.jp/JM/html/procps/man8/vmstat.8.html
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/088vmstat.html

ﾋﾞｸｯ. ∧ ∧ ∧ ∧　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 Σ(ﾟДﾟ；≡；ﾟдﾟ) ＜　　暗号スレ迷い込んじまったぞｺﾞﾙｧ！
　　 　 ./ つ　つ　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　〜（＿⌒ヽ　ﾄﾞｷﾄﾞｷ
　ﾌﾞｯ ω)ノ ｀Jззз

>>527
実際はmod_perlじゃないから、
1) perlプロセス起動→gzipプロセス3つ起動
2) perlプロセス起動→Compress::Zlib 3回使用
のレベルでベンチマークとればそれなりに差はつくのではないだろーか

vipのfreeとか、見てみたいような、見たくないような・・・・(笑)

wani4:~$ free
total used free shared buffers cached
Mem: 516972 492820 24152 431004 10904 75264
-/+ buffers: 406652 110320
Swap: 130748 3360 127388

UpTime(game) = 4:57am up 10 days, 19:28, 0 users, load average: 23.13, 22.45, 25.22

夜勤 ★さんご苦労様です。動作報告-17-で拾いました。

746 名前：夜勤 ★ ﾒｪﾙ：sage 投稿日：02/03/25 21:32 ID:???
UpTime(news) = 4:32am up 34 days, 17:55, 0 users, load average: 2.96, 3.14, 3.63

newsにもぶち込むのでしょうか？

>>538
いいえ、
news が落ちるかもとか言ってたから、だしただけですよん
もっとも軽いサーバの一つなのに。。。

>>539
確かに。。。
3とか、、、gameは100超えてるのに。。。

UpTime(game) = 5:08am up 10 days, 19:39, 0 users, load average: 13.08, 13.99, 19.56

レス有難うございます。
ですよねー。load average見て？と思ったので。
でわでわ。

http://mappy.mobileboat.net/~seek/logview.cgi?srv=news.2ch.net

Newsで実況中　ヽ(`Д´)ノ どうにかしる！

UpTime(game) = 5:13am up 10 days, 19:44, 0 users, load average: 8.81, 10.74, 16.58

vmstat見たけど、凄すぎ・・・・
思ったよりも、ハードウェア割り込みは少なかった。ハードがそこそこいいからかな
システムコールとコンテキストスイッチの数がかなり多いね

つーかシステムコール多すぎ

>>545
CGIプロセス起動の負担は大きそうだ

UpTime(game) = 5:25am up 10 days, 19:55, 0 users, load average: 15.87, 12.07, 13.91

結構　効果があったような気がしますが、どうでしょうか?

>>545
たしか　game サーバは、P3 1G(dual) 1G(RAM) だったと思いますー
さらなる bbs.cgi の改良が必要なのかなぁ? どうなんでしょ。
http://www.yakin.cc/pv200201b.html

dat.gzは、作成にかかる負荷に対して、
リクエストが少ないような気がするのですが、そのあたりはどうなのでしょうか？

dat.gz は　過去ログ倉庫です。
html 化と同時に dat.gz を一気に作成しています。(すいてるときに)
だから　普段は　ただ読まれているだけかと、

PVあてをやっていた頃の負荷の大きかったサーバってどこでしょう？
tv, game, natto鯖とpc鯖では傾向がちがうので（ツールとcgiの比率が）
ある程度判断材料になるんではないでしょうか。

>>549
なるほど、倉庫なのですね。了解です〜。
(それにしても、意外でしたけど、過去ログ参照って、少ないものなんですね・・・)

gameサーバで家庭用ゲーム板だけ
どっか空いてるサーバに移転て無理か・・・・・
あそこは年齢層低いからさ

>>550
どこだったかなぁ。。。
計測日が 1/20 だから、批判要望の過去ログをあされば
わかるかな? 私の記憶では、tv , music , comic あたりだと思ったけど、

UpTime(game) = 5:40am up 10 days, 20:11, 0 users, load average: 15.38, 12.45, 12.54

>>917
そいつ色んなスレで雑誌についてたってマルチしてた奴じゃないの？

何とかしてシステムコールを最小限にしたいけど、どうすればいいんだろ
read.cgiは最適化されてるから、apache、mod_gzip、bbs.cgiあたりが・・・

とりあえず、bbs.cgiは、このスレで出てるgzip圧縮プログラム使えば、
gzip圧縮の起動プロセス数が、3分の一になるから、トオルたんに試してもらいたいな

とりぜず、httpd.confいじるのはだめなんでしたっけ？
.htaccess ファイルを探すのを止めるだけで、１アクセスあたりのシステムコールがへらせそう

あと、mod_gzipのテンポラリファイル作成がかなりシステムコール食ってそうなんで、
スレッドのhtmlデータのgzip圧縮を、mod_gzipからread,cgiで圧縮するようにすれば、少しは軽くなりそう

>>548
dat.gz作成って、過去ログhtml化のとにのはずだから、アクセスの少ない時間にでもやればいいので、
べつに問題ないと思うけど

>>554
誤爆(´･ω･`)ｼｮﾎﾞｰﾝ

なんか見直せば分が変＆まちがいだらけ・・・

>>555
＞あと、mod_gzipのテンポラリファイル作成がかなりシステムコール食ってそうなんで、
＞スレッドのhtmlデータのgzip圧縮を、mod_gzipからread,cgiで圧縮するようにすれば、少しは軽くなりそう

このへんって、具体的にローカルかなんかのベンチ結果って、出せるものなのですか？
Apacheのmod系って、重いとは聞いていますが、どうなんですか？

gz圧縮、、、
「ファイル作るときにzlibでまとめて圧縮する！」がおそらく最適で、で、
その最適を目指さないと逝けない状況な気がするん。

>>558
べつにapacheのmodが一般的に重いわけではない
mod_gzipは、圧縮にcpu使うし、テンポラリファイル作成するため、かなり重いシステムコールを
使うから当然重い
圧縮に、ユーザーモードでcpu使うのは仕方がないが、全体でシステムコールを少なくすれば、
ある程度軽くなるはず

具体的なベンチはないけど、mod_gzipくみこんだapacheに、apachebencheで、大量アクセスを
かけてみたら、システムコールが多く、カーネル時間消費が多かったから

httpd.conf の mod_gzip_maximum_inmem_size の値、どうなってるのかな?
ファイルサイズがその値を越えると、mod_gzip はテンポラリファイルを
使うようになるから、あまりに小さかったら増やしてみては?
ファイルアクセスがかなり減る。

って、httpd.conf はいじれないんだっけ。ごめん。

>って、httpd.conf はいじれないんだっけ。ごめん。

he.net の人にメールで交渉..というパターンだっけか
今の設定だけでも知りたいﾓﾅ

　　　　　html　bbs.cgi　　　　.dat　.dat.gz　　cgi　　　txt　　　all
corn.2ch.net (tv.2ch.net saki.2ch.net)
ch2corn_50463__15761__101003___714____79604__15974__263519
ch2tv___259582__24102__231555___276__420190__40588__976293
saki_____136826______43_______731__3198___10688_____481__151967
　　　　　446871　39906　333289　4188　510482　57043　1391779
-----
ebi.2ch.net (music.2ch.net)
ch2music__174125__18252__93073___244__306574__22862__615130
ch2ebi_______56920____4301__26579__2735___65738___6648__162921
　　　　　　　231045　22553　119652　2979　372312　29510　778051
-----
salad.2ch.net (comic.2ch.net)
ch2comic　128533　19565　189210　 586　236145　30555　604594
ch2salad　　 62818　 2889　 48805　2884　 33204　 5559　156159
　　　　　　 191351　22454　238015　3470　269349　36114　760753
-----
natto.2ch.net
ch2natto　255028　47208　196006　1855　355940　33491　889528
-----
pc.2ch.net
ch2pc　　 161109　28413　441156　1465　325271　91938　1049352

確かvirtualhostの設定が>>563のようになっていたので集計してみた。
鯖のスペックの違いとかありましたっけ？
いずれにせよpc鯖はリクエストの割に軽そう。

mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 0
mod_gzip_maximum_inmem_size 100000


UpTime(game) = 6:09am up 10 days, 20:40, 0 users, load average: 12.30, 12.75, 12.86

やっぱ、mod_readcgi作成が一番利にかなっているような。
・プロセスが減る
・作りによっては、祭りスレの.datをキャッシュ出来る
が、政治的な理由で(he.netとの絡みも含めて)難しいか。

>>565 夜勤さんありがとう。
100000byteか。この値で十分だと思う。

混雑時間帯には、read.cgi は最高100レスまでしか返さない。
100レスで約100kb越えるスレってAA系の板でもあまり多くない。

game での実験は　こんなとこかな?
どうでしょか?

UpTime(game) = 6:32am up 10 days, 21:03, 0 users, load average: 15.18, 16.13, 15.36

>>561
じつは、mod_gzipのい設定でインメモリで処理するようにしても、
テンポラリファイルが作成される

インメモリで処理する場合、圧縮前のデータがテンポラリファイルに保存され、
圧縮後のデータにはテンポラリファイルは使われない

インメモリで処理しない場合、圧縮前のデータも圧縮後のデータも
テンポラリファイルが使われる

むかしのバージョンだと、ちょっと動作が違うけど、いまのバージョンでは
上の説明で多分あってるはず

bbspinkはいじりたくないんでしたっけ？
vipなんか実験してみると変わりそうな気が？

>>569
マジ? ちょっと mod_gzip.c 読んでくる。

566さんのおっしゃる通りmod_readcgiなんか作ったら一番効果あるだろうね。
mod_perlだったら入れてくれるというなら、CでPerlのモジュール書けば
ほぼ同じ効果が得られそうだし、bbs.cgiにも効果あるので一挙両得なんだが。

アパッチのモジュールを作る云々という話は
かなーり昔に却下されたぞ。

game鯖負荷グラフUP
ttp://mappy.mobileboat.net/~seek/up/index.cgi
No.835

>>573
いや、今はトオルも動いてるから違うんじゃないの？

今、過去ログ読んでおります・・・・　<進行中>

>>573
うんうん。。。でもでもー(笑

一応>>483で言ってたﾔｼ
http://pc.2ch.net/test/read.cgi/software/1008169646/43-44n

mod_*を作るのなら......どうせならApache2.xで(w

>>574
どうも　ありがとうございます。

>>577
各処理に任せず一ヶ所に処理を集中させたとき、サーバがこけたとして、
こけたものを救済するのはどうやるですか？

>574
お疲れ様です。
http://www6.ocn.ne.jp/~boyakkie/average.html

gameサーバのグラフ的には、なにか一気に沈静化したような雰囲気がありますね。
効果があったのでしょうか？

私は　とっても効果があったと理解しています。

>>579 うーん，まぁサーバがコケた時云々ということになると，そもそも
普通のやり方でディスクに書き出したとしても，明示的にfsync()とかしなきゃとか
いう話になってしまうと思うのですが......

アクセスが最も集中する時間帯にもかかわらず、負荷は導入前より
低減しているのですから、絶大な効果ありという理解でよろしいのでは？

http://mappy.mobileboat.net/~seek/logview.cgi?srv=game.2ch.net

それでも時々負荷がかかってる？
見られない→リロード繰り返しってことなのかな？

このグラフって１分の方で取ってるの？変動がやけに大きいような．．．

>>582
よかったですね。♪　おめでと！

*･゜ﾟ･*:.｡. .｡.:*･゜ﾟ･*:.｡. .｡.:*･゜
　　　(･∀･)ｼｬﾝﾃｨ♪
*･゜ﾟ･*:.｡. .｡.:*･゜ﾟ･*:.｡. .｡.:*･゜

>>585
http://mappy.mobileboat.net/~seek/logview.cgi?srv=vip.bbspink.com
こちらも

絶大な効果があった　100 -> 50 になった
でも　目標は　1 以下だったりする　、こんなとこ?

>586
グラフでは1分、5分、15分の平均値を使っています。
分けたほうがよかったですかねぇ？

＞588
　？　半角逝った事ないので状況分からないんですが。
　＞570 の書き込みのこと？

>>591
いやvipも変更した筈だけどまだ負荷がかかっているみたいということで．．．

vip はもっと　供給が需要に追いつかないんでしょうね
vip スレ保持数 250 にしてみました。

あらっ　全然効果なかったです。
前までは、スレ保持数を減らすと軽くなったんですけどねー
UpTime(vip) = 7:54am up 24 days, 10:00, 0 users, load average: 169.48, 145.90, 141.86

＞592
　ありゃ？vip変更してたんですか。それは失礼。見落としてました。
　その割りに悲鳴が聞こえないのは既にかちゅユーザーは対応済なのか
vipユーザーは主にブラウザ使ってるのか？

　vipユーザーだけツール使用比率違うなんてことは…ないよなぁ？

２ちゃんは性欲には勝てないのか〜。

見落としって言うか忘れてるよ私……寝よ。

>>595
見落としもなにも・・・・初回限定版でっせ＞vip

ここにもﾎﾟﾁｯﾄﾅ

★ bbs.cgi軽量化開発コンペ ★
http://qb.2ch.net/test/read.cgi/qbtr/1017071166/l50

682 ：トオル ：02/03/26 00:19 ID:a2u5HD06
「先に作ったもの勝ち」じゃなくて、
「どれだけ軽量化できるか勝負」ですよん。。。
674 ：トオル ：02/03/26 00:16 ID:a2u5HD06
なお、これに参加する、かつ、
プロバメールである程度身元を表明できるというかたには、
表に出すより少し詳細なものをメールでお送りしたいと思います。

>>593
良スレがかなりdat落ちでヤヴァイんですけど > Vip

他の鯖も供給が需要に追いつかない気味もあるがね。

kageが簡単に苦楽できるんですが。

半角系は良スレがsage進行でやってることが多いから
早めに戻してね。
２５０はなんぼなんでも少なすぎ・・・

ですなー
どうしたもんだか、

newsは250でも問題無さそうな気がしないでもない。

>>604
で、消えたスレッドはもとに戻るわけ？

datに逝ってしまえば元には戻らない。。。

おいおい・・・
いくらなんでも安易に変更しすぎ何じゃないの？（´Д｀;）

(ﾟεﾟ)ｷﾆｼﾅｲ!!

でも軽くなって…る？
単に生きてたスレが消えちゃっただけか？
http://mappy.mobileboat.net/~seek/logview.cgi?srv=vip.bbspink.com

圧縮によってdat落ちするのは書き込みが古い順だから、仕方ないと思われ。

AJA6H/Ws ◆MPnX7dHAがエンドユーザの立場でぶー垂れはじめました。

1000→700は、やりすぎだろ。

現在進行形のスレまで消さんといて〜。最終書き込み４時間越えでDAT落ちはキツいわ。

一応、その手のスレが批判要望板にある。

圧縮要望スレッド
http://kaba.2ch.net/test/read.cgi/accuse/1016705143/l50

半角二次元板、自治スレも落ちたみたいね
たしか23時の時点で450近くスレがあったから200スレ落ちたのか・・・

>>612
だってこれはいくらなんでも暴走・・・・

>>617
>>615で思う存分、主張せよ。

＞617
　鯖負荷で落ちるのと、延命策とどちらを選ぶかのバーターだし。
　今はこれが精一杯と考えるしか。

半角２次元圧縮し過ぎや。

すげームカツイた。

(・∀・)ﾆﾔﾆﾔ

夜勤さんも苦労するわ．．．ヽ(´Д`;)ﾉ

いくつもの良スレが削除されてしまったことに対して憤慨してもイイですか

>>624
俺も半二住人なので常駐スレが落ちて泣きそうだけど、
憤慨しても意味ないからやめれ

覆水盆に還らず（合掌）

>>625
切ねぇっすよ…。殆どの良スレはあの時間帯殆ど下にいるってのに…

>>624
同じく虹住人。
悔しいけど、仕方ねえんだ。
糞スレもある程度消えた。これからまた良スレを作ってけばいい事よ。
クヨクヨするな、相棒！

http://vip.bbspink.com/test/read.cgi/ascii2d/1017074941/l50
虹板自治スレ。

>>629
大変混乱しとるが・・・

>>628
クヨクヨしても仕方ないんですよね…でもやりきれないです。
荒らしとか宣伝とかこまめに削除依頼だして来た自分のスレが消えてたのが
一番のショックです…。

この騒ぎに便乗してまたクソスレ立ててる奴がいるのも切ないです…。

（･∀･）ｽｯﾄﾞﾚ!がなくなって氏にそうだよ・・・・
あしたからどうやって献立考えよう・・・・

スレの趣旨からはずれとるぞ

愚痴スレはここですか？ 違いますよね？

>>629
ひどいなぁ．．．

>>632
http://vip.bbspink.com/test/read.cgi/ascii2d/1017073843/

この件は終了。
圧縮の件はこちらで

圧縮要望スレッド
http://kaba.2ch.net/test/read.cgi/accuse/1016705143/l50

>599移動しますた。
★ bbs.cgi軽量化開発コンペ ★
http://qb.2ch.net/test/read.cgi/jikken/1017071166/l50

ところでgzipはいっぺんに複数ファイル圧縮できるという点に
なぜ誰一人として突っ込みませんか。

$ gzip index.html subback.html subject.txt

これだとオリジナルが消えちゃうから少し工夫が必要だけど。

>638
　gzipて、permissionとowner/group保持できないんでない?

板のdat落ちって最終更新順だから、スレが下にあるかどうかは（直接）関係ないのにな・・・。

書き込みがないから落ちたんであって、順位が下だから落ちるんじゃないんだよ。

＞sage進行のスレにつらいとか言ってた奴。

>>640　誤爆

>639 gzip.cを読め。

Unixのファイルシステムはよく知らないけど、実況鯖だけでも
RAMディスクで運営するようなわけにはいかないの？
1Gで100Kのスレが1万入るが…

>>639
それはstdoutにリダイレクトした場合(現行)でも同じだと思うが

>>643　誰がその分の金だすんじゃい？

>>282
ということは、更新していれば問題ないということですね？よかった。
いろいろ迷惑をかけてすいませんでした。

>>646
誤爆です。すいませんでした。

あげ。

おはようございます。
今日は夜勤さん、テスト鯖拡大するのでしょうか？

>>640
一応その件は板違い、というか・・・・

>>637
参加しますた。

２ちゃんねるビューアの技術的な負荷軽減策を話しています。

【２ちゃんねるビューア】　巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50


bbs.cgiまわりの件はこちらです

★ bbs.cgi軽量化開発コンペ ★
http://qb.2ch.net/test/read.cgi/jikken/1017071166/l50


圧縮の件はこちらで

圧縮要望スレッド
http://kaba.2ch.net/test/read.cgi/accuse/1016705143/l50


運営関係の話はこちらです。

「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/l50


こんなスレッドもあります。

monazilla Part 3
http://pc.2ch.net/test/read.cgi/tech/1012544484/l50
dat->html化自動処理プログラムをつくるスレ
http://pc.2ch.net/test/read.cgi/tech/1012310594/l50
read.cgi改良スレッド 3
http://pc.2ch.net/test/read.cgi/tech/1002820903/l50

>>649
予定なし〜
ちょっと、お出かけしようかと、

>>653
了解です〜。
では私はbbs.cgi開発の方に注目いたします〜
おきをつけて

各２ちゃんねるツールの仕様比較はこちら。

乱立する2ch用ブラウザの比較 Part3
http://pc.2ch.net/test/read.cgi/software/1015928913/l50

現状は・・・
>>154-163
あたりです。

現状、テストの成果としては、
>>582
>>589

というところです。

>>650　>>641ｗ

夜勤★がいるのはここか？

めちゃくちゃすんなや！
半角二次元で稼働中のスレをいっぱい落としちまいやがって。
板最古スレもこれで落ちた。保守sageしてたのに。。
規定どおりの仕事しろよ！　泣くに泣けんのだぞこっちはYO!

異論（議論の余地）有り
Ａ．monazillaはデフォルトでは巡回等に規制をかける。
Ｂ．ログインした場合のみ巡回等の規制なし。
Ｃ．ツールにお知らせ機能（仕様変更等の）を追加。
Ｄ．ツール側で巡回、更新チェック以外の機能を●もちと●無しで差別する。
Ｅ．２ｃｈ側で●もちと●無しで差別する。

Ａ．については各ツールの最新版では鯖負荷を抑える機能を実装済みが多い（kage等）
　　また、効果があった模様。
Ｂ．については有料ユーザの優遇策は実施されていないツールが多い。
Ｃ．は今回のことのようにツールをはじくような改造があった場合に各ツールにお知らせ
　　機能があれば便利→そんなに頻繁ではないので、各ツールスレをみてもらえばＯＫかも？
Ｄ．ツール側での差別化はそうなってﾎｽｨが、それは各ツールの作者さんに任せる。
Ｅ．についてはアイデアは出ている（スレ立て規制無し（緩和？一日５スレまでとか）

Ａ．の目安は（今のところ、これを基準に各作者さんに実装してもらう？）
　巡回：datをとってくる：スレ取得後にスレ数×２０秒のインターバル
　更新チェック：ゾヌ方式（datから）：スレ数×４秒のインターバル
　更新チェック：abone方式（subject.xtから）：板数×５秒のインターバル（.gzは行わない？）
スレごとのウェイトはダイヤルアップユーザの為に避けて、巡回、更新チェックはまとめてあ
とで行う

結局問題の本質は鯖負荷等の費用と収入の問題。
α：鯖負荷等の軽減策＋β：収入増加策を考える必要有り。

>>659
なのですが、これ今まだたたき台を作ってるという感じ、のようなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

私自身の個人的な感想や見解はじゃまになるそうですので・・・
お願いできましたらお願いいたします＞ツール作者各位さま

昨日の二次板の一件で殆ど眠れず、嫌な夢を見、発熱しました。
これは立派な対人攻撃だと思いますが。

>>夜勤

本質的なところで、Ａの目安に挙げられている インターバルの時間について。

これらの数値は、当然対象サーバごとに持つ数字だよね。
pc.2ch.netとcomic.2ch.netと両方にアクセスする場合
それぞれへのアクセス時間について4秒なり20秒なりの
インターバルを持て、ということだよね？

数値そのものについての議論はとりあえず置いとくとして。

>>659
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

↑全文はこちらにあります。

で、これは向うで言うべきことかもしれないが 一応こっちでも言っておくと

●持ち、●なし の差別化 は 「サーバ側で行う」 のが筋だと考える。
ツール側でどうにでもできることなら、少なくとも私ならクラックします。
（例えばインターバルとかね）

サーバサイドの技術話になるからこっちでいいか。

たぶん　仕組みがわかっていないと思う >>664

>>665
いや、一応ひととおり読んだり試したりしてるから多分わかってると思う。
（つもりかもしれないけど）
だからなおのこと気になるんだよね。それで規制できんのかなって。

>>656
いくらなんでも>>589の発言はド素人だと思うんですが、
夜勤さんってUNIXの分かる技術者ではないんですか?

別に揶揄してるとかじゃなくてね。表現悪くてごめん。
要するにド素人であることが悪いということではなくて...

>>667
どうして　そう思うの?
あなたの実験結果の感想とかは?

>>662
まだ、その辺の話はしてません。

>>664
ログインした時のみ差別化されると、通常は巡回を鯖側ではじくと、
で、ログインしてる場合はスルーさせると、、、そういう意味です。
で、ツール側にはそれが可能な仕様を追加してもらうと、、、

１．デフォルトで制限をかけたツールのみ鯖側で受け入れる
２．その中でログインした場合のみ巡回制限をなくすと

クラックする人数が問題なのよね。
例えば、６０万人中６００人くらいだったら無視できる数字じゃないかとか・・・。

規制の数値を矢鱈とハードにするな（別途受け口がある場合は別。逆にハード
にして、その次善の受け口に誘導することは十分考えうる）ってのは、
クラックまでする強烈な不満をもつ人間が増えすぎて
例えば１０万人以上がクラックしますた、とかになると不味いからで
逆にはみ出す奴を1％以下に押さえられる程度の規制なら
規制としては十分成功かと。

要は、多数を占めるフツーの人が標的ですからね。
積極的にクラックするような人の存在は、ある意味一定の確率での必然で、
仮にそいつが無視できないほどヘビーな奴だとしても、
フツーの人の規制が成功しているのならば、規制の一般論を考え直すよりも
単に個別に狙い撃ちの規制を別途考えるのが賢明かと。

だから、フツーの人を生かさず殺さずに治める規制の数値は
どこなのかがむしろ問題ではないかな。
こりゃまさしく政治だねｗ

A Boneの委員長です。
A.についてですが、現在はまだ叩き台との断りがあるので
細部について問うのは早計なのかもしれませんが、一応
疑問点を書いておきますね。

[各方式のインターバルの取り方について]
確かホットゾヌが選択式になってたように記憶してますが、
このインターバルは後で纏めて取る方式でも良いのだろうか？
dat取り巡回で20秒のインターバルとのことですが、
10スレッド分を一気に取ってしまい、次の巡回を200秒後にしか
出来ない仕様というのも、レギュレーション違反とならないのか？
この方法でもOKならば、通常の使用目的ではそれ程不便でも
ないように思いますが、20秒毎に1スレッドを取得する以外は
ダメだと、心情的にはツライですねぇ。
要は1分で巡回を終えてオフライン読みにして、オフライン中に
インターバルを払いたいんですよね、出来れば。
ただ、「一気に取るのがマズイんだ」という意見もあったと思うので
不可かな？(^-^;
これは開発的にではなく、使い勝手的な問題ね。

[更新チェックと巡回を併用の場合]
このdat取り巡回20秒は、従来のかちゅ〜しゃのように、更新されて
ようと、されてなかろうと関係なしにdat取りをトライする場合を想定
しているのかな？
更新チェックと巡回を併用するのであれば、無用の不可をかけていない
という理屈もあるので、その場合もう少し緩和されるのだろうか？

以上2点が現時点の疑問で、私の個人的な要望としては、
インターバルの後払いOK、更新チェックと巡回の併用の場合
更新チェックのインターバルのみ払えばOKという感じです。
「これが正しい」という主張ではなく、「こうだったら嬉しいなぁ」
という意味で取って下さいませ。
長文すません。

そういえば倉庫のスレを並べ替えて鯖負荷を減らすように努力する
(要するに同じ鯖に連続でアクセスしないように配置する)
って言ってたかちゅユーザがいたけどツール側で再配置すればいいかな。
ダイアルアップユーザの人権が守られてインターバルがまとめでいいみたいだから
頑張ろうって気にもなるし。

>>672
あーそれおれだ。

>>668
> どうして　そう思うの?
CPU1つ(?、まあ2つでも変わんないね))のPCサーバーの
LAが100から50になって負荷が下がったと思うUNIXの
分かる技術者は一人もいませんから、理由は特に述べません。
解説すると長くなるし。

> あなたの実験結果の感想とかは?
データが少なすぎです。
vmstat iostat netstatと
httpのレスポンスタイムくらい見ないとなんとも。

で、別に夜勤さんを非難してるわけじゃなくてね。
もし分かんないんだったらやり方考えたほうが...
と思ってるだけ。

>>647
100 とか 50 とかを　load ave の数値と思っているのは貴方だけという罠。

夜勤★、マジでいい加減にしろよ！
虹板の大事に育ててきたスレッドが全部逝っちまったじゃねーか！

UZEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!!

>>676
人の敷地内で店開いて、所有者に怒られたらあんたは文句言うんですか？
逝ってよしですな。自分の敷地で店開いてください（自分の鯖で板立ててって
ことね）

>>677
(ﾟДﾟ)ﾊｧ?
バカの方ですか？

>675の誤爆さん、じゃあ何の数値ですか?

あんましスレ汚したくないから、これで終わり。

>>678
自分で鯖立てて、自分で管理しろ。消されなくて済むぞ。出来ないなら
おとなしくしてろ。

>>677
じゃあ、あなたはレストランで鞄を置き引きされても
何も文句言わないんですね。

バカは逝ってよし。

>>680
氏ね

>>680
何言ってんの？

>>680
（　´_ゝ`）ﾌｰﾝ

680必死だな（藁

>677はバカだが、>676の抗議はクレームを出す先が違うので>652を見てくだちい。

>>679
10 5 0.1 じゃわかりにくいか、

1,000 500 10
10,000 5,000 100

でもいいんじゃない　きっと　

>>680
頭悪いんならこういう議論に参加するなよ

あ〜あ、終わりたいんだけどな
>>681
次元が違う。
レストランで鞄を置き引き→鞄は自分の所有物
２ｃｈへの書き込み→書き込んだ時点で２ｃｈの所有
DQN春房はカエレ

>>672
インターバルはまとめて、というのは、いつ入ったんでしょね？
驚きました。いみねー。

もうどうでもいいや。そもそもスレと全然関係ないし。勝手に盛り上がってクレ。

>>689
必死だね

クレームを出しても失ったものは戻らないという罠。
過去を顧みず明日を夢見て生きれ。

>>689
著作権って知ってるか？
俺の書き込みは俺の物らしいぞ。
関係無い話っぽいけど。

>>689
春厨はアナタ！

>>689
逝ってよしですな・・・

なんか話にならない・・・
レベルが低すぎて・・・

>>693
禿道。

イタい６８９がいるスレ

>>676-682 ここでやってくれ。開発の邪魔はしちゃいかん。

圧縮要望スレッド
http://kaba.2ch.net/test/read.cgi/accuse/1016705143/l50

>>681　その鞄は、実は自分の鞄（所有物）ではないという罠。

>>670
そんな考え方を私も持ってます。

>>671
>[各方式のインターバルの取り方について]
>確かホットゾヌが選択式になってたように記憶してますが、
>このインターバルは後で纏めて取る方式でも良いのだろうか？

いいと思います。ダイヤルアップユーザのオフライン読みのためにも。

>要は1分で巡回を終えてオフライン読みにして、オフライン中に
>インターバルを払いたいんですよね、出来れば。
>ただ、「一気に取るのがマズイんだ」という意見もあったと思うので
>不可かな？(^-^;
>これは開発的にではなく、使い勝手的な問題ね。

マスで考えれば、実はそんなに1スレごとでもまとめてでも
あんまり変わらない気がします。
ゾヌのように選択式になれば一番良いかと。。。
それは各作者さんが考える問題か。。。。

>[更新チェックと巡回を併用の場合]
>このdat取り巡回20秒は、従来のかちゅ〜しゃのように、更新されて
>ようと、されてなかろうと関係なしにdat取りをトライする場合を想定
>しているのかな？
>更新チェックと巡回を併用するのであれば、無用の不可をかけていない
>という理屈もあるので、その場合もう少し緩和されるのだろうか？

１．従来かちゅ：とにかくdat取得
２．本来の巡回：更新チェック後、更新のあったスレのdat取得
３．更新チェック：更新チェックのみ（ゾヌ方式、abone方式）

１．は言うまでもなく規制の対象とすべきですね。というか禁止かな？（●もち含む）
２．はそれでも負荷は大きいので規制は必要かと←これを想定してます。
３．は前に書いたとおりです。

ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→>>671
西安さん　→>>672

>>687
俺は load average だと思ってる。
>687は「100 が 50 になっても、負荷が高いことには変わりない」
ってことが言いたいんだよね?

>>702
違うって、「先はなが〜〜〜いのう」ということを言いたいんだって。

>>690
ダイヤルアップユーザ対策のためです。
で、マスで考えれば個々が１dat取得ごとにインターバル入れなくても
トータルでは分散化するのではないかと。。。

この辺の話は、批判要望の方がいいと思うので、そちらで、、、
委員長さん、批判要望の方にも来てくださいね。

>>703
ヽ(｀д´)ﾉﾅｴｻｹﾞ!

>>700
本当にそれでいいんですかね＞インターバル。
いっぺんに、ががーっと来るのを回避したくてこんなお話ししているんですよ？
んじゃ、セッションもいっぺんに何本でも張ってよし、ですか？
あとでインターバル取れば。

いま考えましょうよ、っていっているのは、「理屈上こうなればいいんでしょ？」
なんてお話じゃなくて
「お財布に限度があるサーバの上に載っかってるサービスなんだから、
　知恵と工夫で乗り切りましょうよ」
ってお話なんじゃないかとおもてました。
その観点で、理想的な方式を「ツール作者さん達にお願い」するための
たたき台を作ってるんですよね？
私の認識だと、そんな感じなんですけど、どうなんでしょね？

ああ鬱陶しい。関係ない話でスレを流すなボケ。
叩いてる奴も689も同じだ。
掲示板への書き込みに著作権を主張するのも間違い。

投稿確認
・投稿された内容はコピー、保存、引用、転載等される場合があります。
・投稿に関して発生する責任は全て投稿者に帰します。

これ読んだことある？>>693

>703 夜勤さん、>702だって「先はなが〜〜〜いのう」ということを言いたいんですよ。

百歩が五十歩になったと。

これだけ　みんなの労力、時間を費やして
100 が 50 になった、50 も減った、半分になった訳だけど、
目標はまだまだ先で、到底たどり着かないんじゃないかなぁ　ふぅー
と言いたいのよ。同じ労力をかけても次は 50 -> 25 な訳で
その次は 25 -> 12.5 -> 6.25 -> 3.125 となるのが常でしょ?
1 が目的だとしたら　ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>704
ダイアルアップユーザにインターバル入れるのはおかしくないですか？
ダイアルアップのユーザは、すぽんと取って回線切って欲しいわけですよ。
(ソフト上でインターバル入れられたらそれはまずいんじゃないかと)
んで、その代わり、●買って下さいよ、って話じゃないんでしょうか？

＞この辺の話は、批判要望の方がいいと思うので、そちらで、、、
＞委員長さん、批判要望の方にも来てくださいね。

え？

>>709
ヽ(｀д´)ﾉﾅｴｻｹﾞ!

>>710

ちょっと、話こんがらがっているので（ｉｎ　ｍｙ　ｈｅａｄ）
あっちのスレにまとめて書いておきます。

>>704
まとめ取り方式ならすぱっと取った後にどれだけ課せられようがまず関係ない。
だから全然おかしくない。
つーか、●前提の話しかしないね、マジに。
すでに管理者サイド？

>713 まとめ取りというのは特殊な動作なんだから課金前提でいいんでないの。

>>713
いや、私は「まとめてとる」推進派なのですが。。。

夜勤 ★殿
半角二次元のスレでアップしようとしたスレを落とさないでくれますか？
昨日と日中まで有ったものが突然無くなるなんて止めてください。
確認をしてから落として欲しいですね。
半角二次元の処女喪失の画像スレだったかな、確か。
おかげで再度スレあげる事になるじゃないですか。
今度からきおつけてくださいね。お願いしますね。

>>715
自己レス、
「まとめてとってあとでドカンとインターバル」推進派でした。

インターバルの議論は批判要望板のすれの方で議論したいのですが、。。。

>>715
違った。
>>713 の >>704 は >>710 の間違え。

私が想像していた感じを書きます。

１　更新チェック
スレッドに新しい書き込みなんかがでているかどうかのチェックはsubject.txtで行う
各datの確認ごとにdatに対してセッション張らない分サーバに優しい

２　巡回チェック
●ユーザで、ダイアルアップ環境のユーザのために提供するようにしたい
お気に入り登録されたスレッドのdatを一括して獲得して、回線断する
それ以外の巡回チェックは、サーバの負荷とかを考えて、サーバに優しい方式を
考案してやっていきたい・・・インターバルとか・・・

３　subject.txtやdatの場所を変える
クラッキングツールとか、自作ツール系で手軽なアクセスが出来ないように、
掲示板としては本来隠れたデータであるべき(ブラウザから見える必要のない)
これらのデータは、極力ユーザから見えない場所にしまうようにする。
で、ツール作者さんには、たとえば、Monazillaに参加されている方に
情報としてお伝えしたり、アクセス方法をお知らせしたり・・・とか。

４　read.cgiベースのrawモードの使用中止
去年８月の段階で、回線帯域使用量の圧縮のために取り組まれたrawモードなどは、
今後、サーバ負荷軽減のために、別の方式に切り替えていく。
転送量とサーバ負荷とのトレードオフの綱引きが続きそう・・・

５　bbs.cgiなど、cgiやサーバの見直し
bbs.cgiやread.cgiの負荷を削れるだけ削りたいな・・・と。

なんか認識間違ってますでしょか？

>>682
>>683
>>684
>>685
>>692
>>694
>>695
>>696
>>697
気持ち悪い

>>658
アニオタはキモイ

>>720
誰、君？

>>713
巡回機能を許すんだったら、●購入した人って感じにしようよ、
って話の流れだと思ってましたが・・・・
いやべつに私なんの権限もないですよ。管理もなにも。
そんなことより、●無しの人にもダイアルアップ機能ありでいくって
感じになってきてるんですか？＞西安さん
それだったら認識改めますです。おっす。

>>722
確かに私の目にも、巡回機能を許すんだったら、
●購入した人って感じにしようよ、
って話の流れには見えてました
だからこそ寝る間も惜しんで UCK を更新してるし、反対活動もしてるわけですが。
なんか、目的毎に分割したつもりが逆に混同を招いてるような気がしますね。
悩ましいことです。

短時間の負荷がきついってのは、ユーザー総体からのコールが厳しいという
話だから、各ユーザーにまとめてインターバル（といっても個別にウェイトかける
ことを直ちに否定する話にもならないと思うけど）でも、ユーザー総体では分散
つーことになりえないかねぇ？

そりゃ、各ユーザーレベルで分散すれば総体でも分散になるであろうことは
容易に想像できるけど。

質問。どっちがサーバに優しいのかな。

巡回もしくは更新チェックをする際、一つのサーバに複数のリクエストを出すとき、
・Keep-Alive の時間を超えるインターバルを取って、一回ごとに接続・切断を繰り返す。
・Keep-Alive の時間を越えない範囲でインターバルを取る。

>>725
とっとと切断。
他の人のこと考えましょう。

>>723
巡回機能＝一括してどかどかdatとりまくる
更新チェック＝理想的には個別にdatに触らずsubject.txtなどでスレッドの状況を確認する

ということであれば、「巡回機能」は●買ってもらおうよ、という風にいってくれればいいな、
受益者負担って感じだよな、って話だったと思います。
更新チェックと巡回は、上の認識が前提条件で、このスレッドは進行していたはずです。

「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/528-529

昨日までは↑のスレは↑みたいな感じの議論のような気がしましたがｗ

>719 (3)についてはhttpを使う以上無意味でないですか。tcpdumpでｲﾊﾟｰﾂ

つーか、ダイアルアップユーザは制限からテレホじゃない時間帯は余り出没しないのよね。
故に時間帯によっては常時接続な人しかいないわけだから、
ダイアルアップを無視した方向に話が進み易いと思うのよね。
その点について少しでも気に掛けてくれるとうれしいです。

同床異夢のようで。

お知らせ の類はサーバをわけたら？

>>729
たとえば３についてですが、Monazillaに参加している方の申告で、ツール単位に
Basic認証発行して・・・・という感じで、一つの方法は考えられると思うんですけど、
tcpdumpとかリバースしてリソース拾ったりする分については、
それは仕方ないのではないかということなんですよね。
もちろん、厳密にいえば通信法の適用範囲でもありますし・・・・

これは暴論で妄想なんですけど、
４／１はエイプリールフールでもありますんで、丸一日、すべてのdatとsubject.txt
隠しちゃって、全員Web使ってみて、負荷がどう推移するかとか、データ取りできませんかね？

ユーザとしての私個人は「冗談蛇ねえ・不便でしょうがない！」て思いますけど、
この問題ながめさせてもらってるところから見ると、負荷の実体というか、
手がかりがこういう実験で見えないかなぁ？
って気もします。

あんまし意味のないデータですかねぇ。

ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→>>671
西安さん　→>>672

>>734
4/1 だけってわかってるならその日は寝ておしまいだが(苦笑)
問題はどうなってんだｺﾞﾙｧという書き込みの群れで逆に通常より負荷が高くなったり(笑)

常時接続ユーザーがダイアルアップ用巡回を使えないようにできるわけ？

ダイアルアップユーザ専用のログゲットソフトを別に作れば
（ログの形式は各ビューワの形式にあわせられるようにする）
ダイアルアップユーザはそれを使って一日に数回まとめて
ダウンロードすることが可能になるな。
で、既存のビューワは全て「巡回」機能は廃止する。
(更新チェックのみ残す）

>>738
いや、確かにそれで良いんだが、それは誰が書くんだい？

>>739
それによって困る人

>>740
・・・・・。

>>741
いい機会だと思うんだよね。
この機に、作者チームが集まって
ログ取得とか更新チェックとかそのたもろもろの
ライブラリを作っておく ってのも。
2ch.dllってわけじゃないけど。

>>737
問題は「頻繁な巡回」なので、ダイヤルアップ、常時接続関係なく
「頻繁な巡回」を規制する方向で考えてます。
常時接続でも巡回後は一定時間のインターバルをおかないと、再度巡回できない。
っといった感じです。

お話は批判要望板のスレのほうがいいかも。政治的な問題なので。。。

>>743
いやなんでさっきからこっちの話あっちに誘導するの？いいけど(笑)

>733 datはともかく、subject.txtを隠すのって意味あるんですか?
subback.htmlから等価なものが作れるのに。

>>744
あれだけの混乱っぷりを見せた俺としては一つの方がありがたかったりも(笑)

>>745
全く無意味ですよ。
まあ、攻撃ツールが１日ほど使えなくなるくらいじゃないすか？

>>744
いや、こっちはもっと専門的な技術を議論して頂いて、政治的な、
野次が飛び交うようなのはあっちのほうが、ここに迷惑をかけないかと。
賛成・反対が出そうな政治的議論はあっちの方が良いかと。
こっちは技術のbetterとmore　betterの議論をしていただければと。。。

>>745
subbackは、いくらでも名前変えちゃえるそうです。夜勤さん曰く。
既出です。

>>747
ああ、攻撃ツール利用者の切り分けとかに使えそうですね。
subback要求があったらそれは攻撃ツールだ、という感じで・・・

つまり、今みんな一生懸命実装している更新チェックも
当然やりにくく（場合によっては全く出来なく）なるわけだ。

ま、そうしたら攻撃方法かえるだけだよな。
攻撃側だって、なにも上から順番に落書きしたいわけじゃないしさ。

>>749
でも subback へリンクを張ってるところはそう簡単に変えられないよね？
もし、そこが変えれるとしてもどんどん上にさかのぼって変えられないところがどこか出るはず。
そうすると最終的にはなんとかされちゃうかも。
もちろんその前に向こうがやる気をなくす可能性もあるけど。

攻撃側の人間としての仮想人格を作って話してもいい？
その方がうまく話ができそう。

>>752
置換一発で終了のような気がしませんか？

>>753
ああ、どぞどぞ。
ただ私管理側の知識ないので、おながいします。

もっかい質問
そのダイアルアップユーザ専用のログゲットソフトとやらを
常時接続ユーザーが頻繁に使い倒すのを阻止できるの？

>>756
無理。絶対使う。バンバン使う。

>>754
その気になれば 2ch.net のルートからオートパイロットで追えるような。
もちろんインテリジェントに書くのはすっげー難しいけど、あんまり頻繁に変動するとブラウザユーザにも被害が出るからどっこいどっこい。
もちろん、そういう手法では守り手側のほうが有利だけど、必要部分を人間に置き換えることも可能だし。
完全に動的生成にするとツール側はほぼ敗北必死だけどサーバ負荷が増す罠。
そしてアタッカーは何事もなかったように別の手法に切り替え(苦笑)

一言で表現すると　いたちごっこ

批判要望の方に提案文書のドラフトかいてみたです。
ご一読お願いします。

>>756
それは作者さんがどんな感じで実装するか次第だと思うんですよ。
あと、自力でハックできるようなひとって、この際考慮するのは
コーディング時というか、そういうときまでおいといて、っていうと
あれでしょうか？

>>756
巡回がエラーで止まるとかいったことを考慮しなければ、
ダイアルアップから切断までを含めてツール化すれば常時接続側は難しいかも。
でも、俺もそこら辺はそんなに知識があるわけではない。

今思ったんだけど、ダイアルアップユーザだけを確実に認識する
方法があるね。ちょっと時間（とお金）がかかるけど。

>>760
まあ、もちろん最悪論的な見方なので実際にどうかは別です。
ただ、そこまでするアタッカーが本当に出てしまった場合は不便になっただけという罠って話です。
だから、実際にはなんともいえまへん。

>>762
それだと、ダイヤルアップユーザの優遇策になるのでは、、、
常時接続もダイヤルアップも同様にするほうが良いのでないかと、、、
それにいまのところの意見では、常時接続を冷遇する必要はないのではないかと。

ぎじゅつでない常時接続vsダイヤルアップ的な政治的な話になりそうでしたら、
あっちのすれに移動してくださいです。

>>764
一見優遇に見えるのかもしれないけど、実情として更新チェックだけされてれば常接は困らない気も。
まあDAT落ちが激しい板とかもあるかあ・・・。

ダイアルアップユーザはまずほとんどグローバルIPってところ。
プロバイダに割り当てられた範囲内のIPアドレスを配っているから
その範囲を調査すればネットワークアドレスで切り分け可能かな。
当然串は弾く。これは現状の規制とほぼ同じ扱いでいける。

問題は調査にかかる時間とお金。あまり現実的じゃないね。
このへんは政治的な話だけど。

前提条件として

１）ダイアルアップで従量制だったりすると、課金辛い
２）一瞬でも早く回線断したい
３）あちこちうろうろするより、さっと取ってぷちっと切ってオフラインで読みたい

てのがあって、ダイアルアップ用巡回、って発想があると思うんですよ。
常駐しないというか、お祭り参加しないというか、リロードしないというか、なんというか。

>>Basic認証発行して
Basic認証ってパスワード垂れ流すものっていうことは知っていますか？

それに、navi2chや2ch-mode他、原理的にソースを隠すことが不可能な
ツールがあることを認識してください。

だからダイアルアップだとしても、テレホーダイとかだったら
扱い違うと思うんですよね。もう当然の話なんですけどね。
そのへん、巡回の実装でたぶん、考えないといけないと思うんですよ。
ひろゆ子のいうとおり、クラックパッチ一発で何とかなっちゃうにしてもしなくても。

>>768
はい、しってます。
でも、ぎそうするとつうしんほういはんにはなります。

>>733 datはともかく、subject.txtを隠すのって意味あるんですか?
>subback.htmlから等価なものが作れるのに。

全く意味ないと思います。それより、混雑サーバの混雑時間帯はDATへの
直アクセスを一切遮断し、●持ちの人だけread.cgi経由でDAT取得可能、
とかやった方がいいのでは。

>>771
subbackがいまの位置に今の通りに今後もあるとは限らないです。

>>760
どっちかといえばクラックしなくっても
使い方を工夫すればチェックを誤魔化せるんじゃないかという気が
するんですよ
簡単なら口コミですぐ広まっちゃうでしょ
規制関係は性悪説で考えないとバカ見そう

>巡回機能＝一括してどかどかdatとりまくる
>更新チェック＝理想的には個別にdatに触らずsubject.txtなどでスレッドの状況を確認する

If-Modified-Sinceで更新が無かった場合はDATには触りません。statかけるだけ。
subject.txt の大きさの問題、アクセスがsubject.txtに集中することのI/O負担、
なども考慮する必要があります。

subject.txtを転送させて空振りする(304)リクエストを減らすことと、
subject.txtを転送させずに空振りするリクエストを許容することは
注意しないとその負荷(CPU/Disk/Network)はすぐ逆転します。

>>772
つまり、更新チェック機能も否定するということになるね・・・いや〜ん

規制するのはあれか、巡回機能を悪用するヤツを閉め出すため？
それとも、鯖の負荷を低く抑えるため？
てっきり後者だと思いこんでいたのだけど、
どうも両方を目的にしているっぽい。

どちらか一方に絞らないと無理。

２ちゃんねるの転送量が増大し、運営費を圧迫している(昨年８月の問題以降)
これに対応するべく、read.cgiでのgzip圧縮やMonazilla（２ちゃん閲覧ツール作者さんの集まり）
が開発するツールなどで、様々に工夫をしていた
そうこうするうち、転送量の圧縮は出来ているが、今度はサーバの負荷が増大して、
運営に支障があるレベルになってしまった（今回の問題）

対策のため、現在choco、love、vip、gameなどで、これまで許可してきたツールでの閲覧や書き込みの
方式を変更した。変更は以下の通り。

●dat、subject.txtの取得=>Monazillaツール（但しkageは0.99.1以降）でのみ取得できる。
●bbs.cgi=>kage 0.99.1未満をはじく。
●read.cgi=>Monazillaツールをはじく。

>>772
板のトップページをパースすればすぐ分かります。フォーマットが変わっても
解析なんて簡単です。他の部分を作る方が大変。

この変更によって影響がでる可能性のあるツールは、以下の通り
現在も影響があるツール：

●MapleSyrup Ver.0.05g (read.cgiを使っているためレス取得不可)
●ぎこはにゃ〜ん　0.22.04 (read.cgiを使っているためレス取得不可)
●Hikky 02/01/22 版 (read.cgiを使っているため新着レス差分取得不可)
●Gickoブラウザ改良版 スレリスト取得不可(read.cgi使用)

影響があったが、バージョンアップにて対応可能なもの：

●A Bone Ver.1.23 (V1.23bで対応)
●かちゅ〜しゃ+kage (Ver.0.99.1.2で対応済)
●ホットゾヌVer.1.0 β2.1.4以下でスレリストを取得できない (β2.1.5で対応済)
●えまのん (3/24版で暫定対応、ただし差分DAT転送に対応していないので要注意)
●マカー用。エレメンツ (Ver0.992β で暫定対応)
●jane 低速回線・ダイアルアップ設定でレス取得不可 (高速回線設定に変更すればok)
●navi2ch (read.cgiを使わない設定にすればok)

なお、この負荷低減実験は、今後順次、ほかのサーバに拡大していく予定。

※上記以外のツールの情報をお持ちの方は、
　【２ちゃんねるビューア】　巡回機能の巻。Part3
　http://pc.2ch.net/test/read.cgi/software/1016905060/l50
までお知らせ下さい。

>>779
ぎこはにゃーんもHikkyも既に対応版出てるよ

>>778
全体の問題と、そういうスキルがある人一人一人にまで意識してサイトを構成するか、
というのは、コスト意識のバランスなんだと思うんです。
今ここでやっていることの、目的はなんなのか？
っていうことに尽きると思います

>>780
次スレのテンプレートに使いたいので、教えていただけるとありがたいです・・・・

>>782
monazilla.org みなよ

>>783
お前が調べて書けよ、って感じっすか？

素朴な疑問
なぜにそこまで従量制にやさしいってなことを重視しますか？
別に従量制で余計な金がかかっても知ったこっちゃないじゃないですか。
言葉は物凄く悪いですけど。
それでも2chを利用したければその人の勝手じゃないですか。
便利に使いたければそれ相応の金を出すってのがすじってもんじゃないですか。
それが2chにであれ、プロバイダにであれ。
やっぱ巡回なんて金出さなきゃ使えないようにするのがいいじゃないですか。

しろゆきも言ってるように。

>>781
言いたいことは、subject.txt を隠したところでその意味は限りなく薄いということ。
それよりは、もっと現実的かつシンプルな提案として >>771 を書いたのです。

>>785
俺が従量制でできるだけ金を払いたくないから。
そしてそういう人が他にもいるから。
そういう話は対象を置き換えていくときりがない。

>>786
＞言いたいことは、subject.txt を隠したところでその意味は限りなく薄いということ。

私そうは（限りなく意味が薄い）思わないんですけど。

それに、subject.txt隠したいというのは、転送量とか負荷の問題以外のところからも
あがってきているようですよ。要望として。

>>784
影響があったが、バージョンアップにて対応可能なもの： (追加
●Hikky (02/03/26AMup版で対応済)
●ぎこはにゃ〜ん (0.23.03 で対応済)

あと、Mac用ツールはどうなってんだろう、
・iTteyoshi
・マクモエ
・Ahyazilla
・Fuuun
・CocoMonar

ていうか、サイト設計として、datやsubject.txtやSETTING.TXTっていうものは、
一般ユーザが容易に接触できるところにおいてあるべきものかという話も、
どこかにあってしかるべきじゃないでしょうか？

これは、純粋に私の私感なんですけどね。

想定する近未来：
・「串制限中」などと同じように「ツール制限中」などの言葉が普通に使われるようになる。
・●持ちの人は、串制限が緩和されるように、ツール制限も緩和される。
・「2ちゃんねるを便利に見たい場合はコレ！」「混雑時間帯でもスイスイ巡回。面倒な操作は不要」

>>789
ありがとうございますです

>>790
腹が腹痛、私の私感(ぼそっ

>>791
ｶﾞｸｶﾞｸ(((((((( ；ﾟДﾟ)))))))ﾌﾞﾙﾌﾞﾙ

>>791さんは、転送量の問題と、サーバの負荷の問題は、
どうやって解決するべきだと思ってらっしゃいますか？

>>776
鯖の負荷を低く抑えるためには、やたらめったら巡回する人たちを
どうにかするのが近道なんじゃないの？

まあいいや、みんなあんまり興味ないみたいだから
この話はやめる　お邪魔さま

この変更によって影響がでる可能性のあるツールは、以下の通り
現在も影響があるツール：

●MapleSyrup Ver.0.05g (read.cgiを使っているためレス取得不可)
●Gickoブラウザ改良版 スレリスト取得不可(read.cgi使用)

影響があったが、バージョンアップにて対応可能なツール：

●A Bone Ver.1.23 (V1.23bで対応)
●かちゅ〜しゃ+kage (Ver.0.99.1.2で対応済)
●ホットゾヌVer.1.0 β2.1.4以下でスレリストを取得できない (β2.1.5で対応済)
●えまのん (3/24版で暫定対応、ただし差分DAT転送に対応していないので要注意)
●マカー用。エレメンツ (Ver0.992β で暫定対応)
●jane 低速回線・ダイアルアップ設定でレス取得不可 (高速回線設定に変更すればok)
●navi2ch (read.cgiを使わない設定にすればok)
●Hikky (02/03/26AMup版で対応済)
●ぎこはにゃ〜ん (0.23.03 で対応済)

なお、この負荷低減実験は、今後順次、ほかのサーバに拡大していく予定。

※上記以外のツールの情報をお持ちの方は、
　【２ちゃんねるビューア】　巡回機能の巻。Part3
　http://pc.2ch.net/test/read.cgi/software/1016905060/l50
までお知らせ下さい。

日本国全てで常時接続が実現してないのが現況のようなので。

規制して数を減らす、という政治的な話ばっかりだな。
httpd.conf触らしてもらえるようにするとか、そっちの話のほうが
てっとりばやくて効果絶大なんだけど、それは
政治的な話なのかい？それとも技術的な話なのかい？

>>795
巡回・更新チェックといった見方ではなく、ツールによるDATへのアクセスを
一旦すべて遮断した上で、●持ちの優遇策を取る。

●持ちの人の絶対数は将来に渡っても○の人より少ないわけだから、
read.cgiでsidを判定した上でのDAT転送といった、重めの処理も許容できると考える。

ここでのポイントは、すべて鯖側でアクセス可否が判断されるということ。
UAを偽装しようが、クライアントのソースを書き換えようが、有償ID/PASSを
盗まない限りはどうしようも無い。

また、一律全サーバ・全時間帯で同じ仕様にするわけではなく、時間帯ごと・鯖ごとに
制限をかけわけることで、ある程度リソース(この場合DAT)をフリーで解放する。

つまり、実況版は別に見ないから無料ユーザのままでいいや、みたいな逃げ道を
確保しておくことで「運営側からの強い圧力」といった印象を抑える心理的効果も期待する。
(この場合の対象はツールユーザ・ツール作者・クラッカー)

>>791
串無しでIEを使ってる人（想定している通常ユーザ）
は何の変化もないでしょうね。

>>799
がいしゅつです

>>799
　>>308　>>314

>>803
Thx!

Dreamさんにsubjext.txtを隠すことの利点を解説して欲しい人の数→(1001)

>>805　夜勤さんに聞くのが筋と思われ。
　もっとも答えない気がする。

>>803
そうでしたか。
今議論されてるレベルなら、どうころんでも規制をすり抜けられます。
結局性善説の上での話ですから。
性悪説で話を進めるならサーバ側での対処が必要なのに・・・

これじゃなにゆってもだめぽ

>>807のラインでいくと、性悪というより最早敵対視してると思われ。

逆にいえば、今の話がまとまってほしいとも思う。
だって規制が無いようなもんだからね。

>>793
気分転換に煽っていい?
「彼の私感」という言葉も存在するので、「私の私感」というのはおかしくない。
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%8E%84%8A%B4&sw=2

>>805
こまったなぁ。
ある程度、このスレと、批判要望の方の発言読めば、夜勤さんとトオルさんとひろゆ子さんが
隠したがっているという意向が伺えると思う。
だから盲目的に「隠そうよ」っていうわけじゃないけど、
一つは、イリーガルなツールに、ある程度責任を負わせられるって事。
二つ目は、Monazillaつーる(便宜的にたとえているだけですけど)みたいな、
２ちゃんの負荷とかの事を考えて下さる作者さんのグループに、
認証手順とかを提供することで、ほかのツールとの差を発生させることが出来て、
その差の部分で、そうじゃないツールと、サーバ的に区別する手段が
得られるような方策が将来的に取れるか、ということ。

ここまで書いて思ったんだけど、どうして、subject.txtが隠れてしまうことに
拘泥するのでしょうか？拘泥する必要がないと思うのですけれど。
Webでも、ツールでも、通常使用の範囲では今まで通り提供されるのに。

>800
dat遮断したらread.cgiへのアクセスが集中して全鯖即死です。

>>810
また一つ賢くなったよ。
ありがとう。

>>812
そうなるのかなぁ。
read.cgiへの呼び出しは、localhostからのもの以外弾いてみたらどうでしょう？

別に「フツーのユーザー」（←大事）が困らないんだったら隠しちゃえ、隠しちゃえｗ

>>811
現状では私もある種非Monazillaツール扱いなのよね(^^;
(すでに monzilla.org で紹介されてはいるが)
開発始めるにあたって隠れてたらやる気なくしただろうねえ。
まあ、そこらへんは感情論であって、正規の手段で取得できるなら問題はないかな。

>811
subject.txt隠したら負荷が増大するだけで軽減にはならない。
subject.txtを隠す云々は荒らし対策なだけで、今回の件とは関係無い。

>>812
現在呼び出しの５０％以上を占めるというツールユーザが全員
負荷の軽いdat読みをやめてIEなどのブラウザでread.cgiを呼ぶことになるわけだからなぁ。

>>816
そうなんだよね、結局、monazillaツールって何？ってなっちゃう
んだよね。
別に2chがライセンスしてるわけじゃないし、著作権持っている
わけじゃないんだよ。
そういうのに乗っかって規制する事が出来るのかと言うと、不
可能とは言わないけど、かなり難しいんだよね。

>>818
ぎゃー

>>812
だから全鯖にはせずに一部の鯖・一部の時間帯だけにする。
read.cgi HTMLパースするツールが現れたら作者に警告する。

>>817
その積算根拠があるとうれしいんですよ。

>>821
作者がソースを垂れ流して改造版が出回ったら？

＞811
とりあえず、gikozillaプロジェクトの発足と
その現状については関知している？
＃今はgikozillaもたいがい氏んでるけどな。

>>819
いえね、そういう意味では、いわゆる２ちゃんねる側の人たち、
夜勤さんとかひろゆきとか、トオルさんもかも知れないけど、
気を使っていると思いますけどね。
ただ、サーバが破綻している現状があって、この現状をおかしい、
って思わない人がいるんならしょうがないでしょうけど、
おかしい、とおもって、協力しよう、って思う人がいたら、
単純に私は可能だと思いますけどね。
●機能の実装だって、そういう経緯でされたんじゃないんですか？

>>824
不勉強ですいませんです。

>>816
ちょっと、その辺は私の感知できる部分ではないし、
私自身Monazilla不参加なので、まずいっすかねぇ？参加しないと・・・
どうなんでしょ？

>>819
現時点でのmonazillaツールの定義は「有償IDの認証機能を備えている2chブラウザ」
だと思われ

そして有償IDはクライアントの特定や制限に利用できる有効な手段と思う

subject.txtのアクセスに、なんらかのパスワードが必要なようにしておけば、
それを正規に得ていないツール/会社からのアクセスを「不正アクセス」と
して、罪に問うことができますね。
管理者がパスワードを「みだりに知らせてはならない」としておけば、あとは
実際にその機密性が保たれているかどうかは問題ではない。

日本の法律が、米国に所在する2chのサーバに適用されればですけど。

一番簡単なのは、2chが自分の責任でツールを提供する事なんだけど
（monazillaのツール作者にお任せでなく）
でも、現状ではそこまで出来ない。
結局、ツールで規制する事には限界がある（溜息

単純明快に
「subject.txtもdatも基本認証の中に隠しちゃえ」
みたいなことが言えるのは、私がニュートラルな場所にいるからだと思ってるんですけどね。
夜勤さんは、このスレッドのどこかで、
「私からそういうことを言えた義理はないです」みたいな事いってましたし。
「管理者以外の人間が批判されたりしませんか？」って気を使ってましたし。

>>829
だからsubback.html(またはそれに相当するもの)を使うだけだってのに..

>>829
運用会社が日本にあるのだから、専管裁判所は札幌地裁になるんじゃないっすか？

>>832
この話回ってますね、四週目くらいです

>>832
subback.htmlにアクセスしてきたIPを弾く機能って、実装難しいですかねぇ？

IPによりアク禁をかけるのは、それじたいは難しくないが、
そのIPリストを誰が管理するのかということと、
レイヤー8以降の問題が山積みではある。

>>836
2ちゃんねるの場合 political layer の所が難しいよな。
Big-Server はサーバの表面程度しかいじれない。
ひろゆきはやる気もスキルもない。

>>835
subback.htmlにどういうアクセスをしてきたものを弾くんでしょう？
通常使用でも見ることがあると思いますが

gikozilla騒動について知らない、歴史を軽視するような
香具師は、monazilla part2の、、、あ、offaw落ちか、、、
http://www.google.com/search?q=cache:EU7vRQnwjxQC:pc.2ch.net/test/read.cgi/tech/1005282763/+&hl=ja
140〜を参照セヨ

>>838
その辺は今話し手も仕方ないと思いますし、実装するとしたらなおさらいわないと思います。
私実装する人間ではありませんし、どんな権限もないです。

ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→http://pc.2ch.net/test/read.cgi/software/1016905060/671
西安さん　→http://pc.2ch.net/test/read.cgi/software/1016905060/672

過去ログを縦読みしたけど、
昨日からなーんも進展がないような気がするんだけど・・・^^;

>>842
現状の2ちゃんねるの問題が、それだけ深刻だと言う事

>831
転送量や負荷を抑えるために
subback.htmlより小さいsubject.txtを読んだりread.cgiより負荷の小さいdat直読みしたりするツール
の使用が推奨されてるわけで、
subject.txtやdatを隠して誰が得するのか説明しろｺﾞﾙｧ(ﾟдﾟ)

ゲイツか？

subject.txtを使った荒らしが減る。

TCPの3-Way-Handshakeは重い、という話をきいた
ことがあったので、あちしのツールではKeep-Aliveによる
Persistance-Connectionがなるべく途切れないように
しているわけだですけども、intervalがあるなら、当然
Connectionは毎回切れるわけで、そういうものなのか、と。

intervalを間に挟んだり、複数の鯖を交互に使用したりして
軽減される負荷というのは、Keep-AliveしてHandshakeを
削減するのよりも大きいのかな？という疑問はありますです。

>>844
一定の枠を用意して、みたいないいカタすると官僚のようだけど、
ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
ツール作者さんには、subject.txtやdatを公開するって形だと、どうなんでしょね？

＃ずっと私は、それを提案してきているんですけど
＃誤解されていますか？

公式発表的には、subject.txtは隠されているのですが。
つか、あなた、ブラウザから取得できますか。

>>847
それなら隠すといわずに取得に制限を加えると言った方がいいのでわ

>>846
インターバルを挟む、という思想は、ツールによる断続的で集中的な
リクエストを防ぐ、という視点に大きく立脚しちゃっているものだと思います。
作者さんの視点で、どういう方法が、サーバの負荷と転送量という問題に対して
効果的である、という、啓蒙というか、教育というか(私みたいなのに対して)
をしていただけると、とてもうれしいです。

>>846
>>725-726 ではとっとと切断、って言って終わってるけど、
もうちょっと考えるべき事だと思う。

「じゃあ Keep alive せずに Rapid fire しろっていうことか?」
と誤解する人が出るのが怖い。

>>849
ああなるほど。

＃ここまでに、このスレッドでも前スレでもしつこくさんざん書いてたから了解済みだ
＃という思いこみでした。
＃すみませんでした

>>851
是非お願いします。
SYN ACKの認証が正直きつい、というのがそもそも、dat直取りで巡回を
されたくない、という話の始点だったと思うんです。
私自身は、その程度の認識しかなく、
「だったらどうやるのが効果的なのか？」
については、是非お聞かせいただきたいと思っております。

もちろん、dat直取りのもう一つの要因としては
転送量に影響する、というところもありますけど、これは、
要求されるのはHEAD情報だけで、datを直に取ってるわけではない、
というお話だと思いましたが・・・・
その場合でも、SYN←→ACKのハンドシェイク的に、サーバ負荷につながっていないのか？
とか、いろいろ、お聞きしたいことがありますです。

あと夜勤さんに、
http://www.yakin.cc/pv200201.html
には、HEAD要求は含まれていますか？というのを確認させていただきたいと思います。
PVという言い方の印象では、GETのみ、で、ページ単位のカウントのような気がします。
(イメージファイルとかそういう者を除いている、という意味で)
お願いします。

>>843
なるほど

場合わけをきちんとしようや。
・更新があるばあい
　・Head(stat) [+ Get(read)]
　・ims-Get(stat&read)
・ない場合。
　・Head(stat)
　・ims-Get(stat)
で、どっちにしろ、更新があれば中身をみたくなるわけで、
むしろIf-Modified-SinceをつけたGetの方が軽いのでは？
というのがすくなくとも8ヶ月前の結論だったわけですが。

>>854
あの〜普通に巡回といわれるものはすべてIf-Modified-Since付きのGETですよ。
巡回時に自動でHEAD→GETとわざわざ無駄なことやってるものは即刻修正すべし、です。

>>857
ああ、はい。
巡回じゃなくて、更新チェックですよね。はい・・・

＞ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
＞ツール作者さんには、subject.txtやdatを公開するって形だと、
＞どうなんでしょね？

ところで、これは現在のsubject.txtの状態と具体的に
どのあたりが異なるのでしょうか？

>>859
いまはhtaccessやcgi内部で判別してアクセス受け付けてるようですが、
たとえば、基本認証使ってリクエスト受ける、というイメージです。
イメージ的には。

>>859
ぎこはにゃ〜ん作者登場。

>>860
ナニを認証するのさ？●？

>>860
それが何の解決になるの？鯖負担が増えるだけでは？
荒らしツールはどれかのツールに簡単になりすましができるけど。

>862
ツール（と作者）、じゃないかな。
セキュリティ的にはヨワヨワでないも同然だけど、
そこを不正アクセス禁止法で補助するような感じがする。

>>863　荒らし対策の話をするスレなのか？

>>865
違うはずなんだけど、まとめ役がそっちに話を持っていくんだもの。

>>860
イメージとか、イメージ的では正直意味がとれないよ。
具体的な説明求む。

>>867
すいません。イメージなイメージ的にエクスキューズな単語ですけど、
＞たとえば、基本認証使ってリクエスト受ける
これそのものずばりではないかと愚考します。

>>866　責任転嫁すな。

ん、だから普通にsubject.txtをGETしても
HTTP/1.1 401 Authorization Required
が帰ってきて、ちゃんとパス送らないと
受信できねって事だろ。
で、このパスを勝手に解析すると不正アクセス防止法に触れる可能性があると。

>>865
荒らしが過負荷の要因になっていない、または、別の手段で対応が出来る、
ということであれば、そういう仕組みは一切要らないかと思います。
たとえば、特定の業者がdatクロールして利益を得ようとしているわけです。
たとえば、全くランダムなdatから書き込みを抽出して、それを、
subject.txtで特定のスレッド拾って、bbs.cgiにPOSTしたりしているわけです。
そういう行為を、負荷低減策として検討する必要がないのであれば、
datもsubjectも、現行のままでよろしいのではないかと思います。

>>870
法律なんか気にするな！

>>871
それが問題なんだからそっちを対処しようよ。

手に入れたデータまたはその統計を商業利用しようとしている
ところから金を取れるように何か利用規定を設ければいい。

具体的には抜き打ちでIP統計とって、異常に多いところの
IPがどっかの会社だったら 「金払え」 って言えばいいよ。

抜け道はあるかもしれないけど、それはそれで
バレた日にはその会社は２ちゃんねらに潰される

抜け道はあるかも → 抜け道はたくさんあるけど
だった。

少なくともちょっとは金取れるようになるよ。
そしてその金で回線増強なりなんなりできる、と。

>>873
でもですね、やっぱしあれなんですよ。
荒らしが発生していない日でも、厳然としてサーバはぱんぱん
帯域かつかつ。なんだそうです。

>>868
いや、基本認証使ってリクエスト受けると、基本認証する分だけ
負荷が増すと思うんで、その辺どう考えてるのか知りたいなと。

現状だとUAをモナジラと詐称するだけで、
荒らしツールだろうとなんだろうとsubject.txtは受信できちゃうわけで、
しかもそれは法にはふれない。犯罪じゃない。
（UAを偽る＝鯖を騙す＝詐欺罪って話もなきにしもあらずって感じらしいが）

そこを認証にすれば、不正アクセス防止法違反という立派な犯罪にできる。
だから荒らしツールを抑制できる。
悪質なら訴えれば逮捕される。
って事だな。

まぁ、俺ならそんな事されたらsubback.htmlで同じ事するけどね。
それもなくなったとしてindex.htmlから生成すればいいし、
それもだめだったら
http://pc.2ch.net/test/read.cgi/software/1016905060←ここのキーを
現在時刻からさかのぼって存在をチェックしてランダムに荒らすようにだってできる。
ブラウザで見れてカキコできる時点で、なんでもできるわな、そりゃ。

つか、むしろそういう規制された方が燃えるね。
なんとしても荒らしてやろう！ってな。

>>875
この話は批判要望に書くべき内容だった。すまんこ。

荒らしが原因の日もあるだろうけど問題なのは
慢性的にクロールしてる企業がいるで重い
ってとこかと

かちゅーしゃのアクセスが多い、ってのはそういう企業が作ったツールが
とりあえず有名なかちゅーしゃのUAを偽ってる、ってパターンが多かったりしてね

でもそれは、オープンソースの死だよね。
dat、subject.txtのgetにpassが必要で、
それをツールに埋め込んでしまう時点で。

なにか起死回生の良いアイデアありませんでしょうか？

>>880 >>768 で一度指摘されたが、返答なし
オープンソースの場合、隠しているとはどう考えても言えないから
法に頼るのも難しいと思われるが

>>880
パス埋め込んでもかんけねーよ。
認証なんてなんの暗号化もされてないんだから、
ローカルでプロクシ立てて通信内容のぞき見れば、
すぐにパスなんて分かるっつーの。
仮にプロクシ立てられなくてもTCP/IP通信内容をのぞき見るツールだってあるんだし。

というか自分がなにを発信しているか、受信しているかはすぐわかる。

>>882-883
なんか代替案がありましょうか？

BASIC認証はたとえなので、Digest認証くらいは
使うものだと当然思っていましたが、、、
別にこれがSSLのClient Certificationでもそんなに
話は変わらないと思うのですが。

誰かの書いた内容について、批判したり、だめな面を指摘するのは
すごく簡単だと思うんですよね

でも、ここ重役会議やっているわけじゃないんですよ。
どうしようかね？って話してるつもりなんです。

私の提案に不具合や不足があったらとっとと引っ込めます。
良い案を考えていただけるととてもうれしいんです。
(否定すんなよ、ていうんじゃないですよ、もちろん(笑))

だから平凡なパスを埋め込むというのは愚行。
送信内容の一部を暗号化して・・・ってのなら効果はあるけどね。
一部にPGPを使うとか。（遅そー）

そもそも、大体subject.txtをいかに強いセキュリティをもって隠したところで、
subback.htmlだってなんだってあるんだから無駄って話でしょ。

>>886
ええ、仕様を決めているんではなくて、要求分析というか
まだそこまでいっていないブレインストーミング的な話ではないかと思います。
そう宣言しているレスが、残っているはずです。

>>889
なんでそこではなしがとまっちゃうかな？
ずっと同じ方ですか？
じゃ、どうすればいいの？

公開鍵が公開されてなければ（ツール内に隠蔽されてれば）いけるかも。

しかしこの方法はソース丸見えなのには(j2ch-cashだっけ？)使えないな

>>891
どうしようもないって事かと

>>894
いや、あなたがそういう感想なのはわかりましたので、
だったらもうあなたの意見わかったのでもういいです。おつかれさまでした。

どうせやられるんだからsubbackよりsubjectの方がまだましだ。
異様にアクセス多いIPだけ完全アクセス禁止にしろ。

>>894
今回の問題については、100% 完全無欠のシステムを作るのは無理。
だけど、できることはあるはず。UserAgent 詐称だって、
それをやる人がどれだけ存在するかどうかの問題。

規制したことで、トータル的に負荷が減るならやる価値はある。
そのためにも統計とデータが必要。
これからの2ちゃんねるは、様々な実験が必要なんだよ。

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/l50

ちょっと早いですけれど、次のスレを用意しておきました。

>>896
そうだね。それが一番現実的かつ簡単。

そのIPアドレスがどっかのプロバイダでないにもかかわらず
アホみたいにアクセスが頻繁だったら禁止ってのはいいかも。

>>875
荒らし対策しても意味無いってこと？

ツール側と鯖側でsubject.txtを強度な暗号化して通信したとしても、
結局自分のPCから発信してるわけで、
串とかで通信内容のぞき見られたら、
荒らしツール、dat総ざらいツールでもそのまま使えちゃうんじゃないの？
まったく同じリクエストを送信するだけじゃないの？

>901
は、SSLについてもっと勉強してください。

>>900
先日のkaba鯖アタックのときは、対策が非常に効果的だったよ。
対策してないときは、ロードアベレージ 150 は軽く越えてたはず。

>>898

>>1のテンプレが古い。

>>901
でも、その行為は、これまでのグレーではなく、
レッドになるわけですよね？法的には。

「そういう使い方をされたくないために意図された」
ものを乗り越えるんですから。

>>904
ああ！すいません。

>>904
http://pc.2ch.net/test/read.cgi/software/1017161683/10

このあたりでお許し下さい。

>>903
そうなんですか？
対策効いて沈静化したのか、攻撃終わって沈静化したのか
わかりませんでした。

どなたか批判要望板の容量を教えてください。
１０００行く前に１０２４ｋの制限でdat落ちする可能性がおおいので
長文レスが多いもので、、、って漏れか（ｗ

>>909
このすれも300kも全然いってないから大丈夫

>>910
こっちあげでいって、９５０くらいまで使いますですか？
わたし、いったんお休みいたします。
早めにスレ立てましてすんません。

GickoBrowser修正改良版
Information

(2002/03/26)　暫定的にかちゅのUAを借りてsubject.txt取得するようにしました

>>912
なんでかちゅ・・・・。
しかもそれって実質 kage の UA よね・・・。

◆hAnYaNVA さんじゃないけど、インターバルの件でどうしても納得いかない。

「インターバルを設ける理由」から
「巡回を不便にして巡回自体(回数/スレ数)を減らす」目的を除き
純粋に「複数のリクエストを送る必要がある」場合。

Keep-Aliveしたまま接続断を待つ/サーバーを待たせるのは論外とし、
同じサーバーに対してのconnectionは
一つに限定する(タブブラウザなどは複数？)場合、

本当に、
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
が、
　connect-
　　request-response-request-response-request-response
　-close
よりサーバーに優しいか、結論は出ているのかな？

詳しい条件等は全然知らないので、2chには当てはまらないかもしれないけど
Apache自体はKeep-Aliveの実装によって50%近く負荷が下がったらしい。
game鯖等が軽くなったのは、インターバルを設けた効果ではなく、
単にread.cgiのrawモードを不可にした効果に思えるのだけれど。

リクエストの集中が問題というかもしれないが、
仮にKeep-Aliveにしも、サーバーが処理するリクエストは、
各接続に対して同時に１つだけなのだから
接続要求の度にacceptすることを考えれば
Keep-Aliveしたままの方がトータルの負荷は少ないと思う。
そもそも、同時接続数が256では足りないような状態のサーバーに対して
単独のクライアントからのリクエストが連続しない程度で
負荷分散になるとはとても思えない。

それでも、Keep-Aliveにしたら次のリクエストを待つ間の
idleなconnectionが負荷を高める原因だと言うのならば、
リクエストをパイプラインして送ればいい。
　connect-
　　request+request+request - response+response+response
　-close
これならidleなconnectionも発生しないし、無駄なconnect/closeもない。
HEAD等の軽いリクエストを数十件まとめて送り
レスポンスにかかる時間を比較しすれば
サーバーが短時間で処理を完了して解放されるのがわかる。

どこか間違ってる？あるいは何か見落としてる？

話が追いきれてないけど、書いとく。
# 今は話がループしてるっぽいし。

●で認証を行うか、ツールで認証を行うかと聞かれれば、
私は●を進めますが。何故かというと
1.ツール認証はhttp内で行うには抜け道が多いから
2.●で認証は無料ユーザにも発行することができ、
　ココの負荷を把握することができるから。
の二点が理由なんですが。

●の発行で無料用の話って出てないよね？

【２ちゃんねるビューア】　巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50
でいま、２ちゃんの負荷低減とかを話してます。

ところで、２ちゃんねるはいま、htaccessを使ってRewriteCondをつかい、
各ツールなどにdatなどを供給している訳なのですが、
「httpd.conf」に一本化し、htaccessを一切使わないようにすれば、サーバの負荷低減がはかれる、
というお話をなさった方が居られました。
お聞きしたいのは、この方法をに変えると、どのくらい負荷が低減するのか？
といった、見積もり的な試算は可能なのか？ということと、
具体的に、これを裏付けるベンチマーク結果などは、存在するのか？
という２点です。
もし、おわかりの方、この問題に詳しい方が居られましたら、上記スレッドで
お話をいただければと思います。
よろしくお願いします。

マルチポストしてきました。うざくてすんません。

スレが立てられない。
だれか2ちゃん専用ブラウザ「かちゅ〜しゃ」Part588を立ててくれ。
http://pc.2ch.net/test/read.cgi/win/1017034701/904

>>917
>>314
できもしないこと話してどうするんですか?

>>919
はい。
劇的に効果があるんだったら、再度提案してみたいし、もし、
劇的に効果があるなんて言えない内容だったら、もう忘却してしまったらいいかと思っただけです。

>>917を夜勤に無理強いする。

負荷軽減を要望するが、変化を望まない夜勤がボトルネック。

>>920
今すぐ忘却してしまっていいと思います。

Dream ★さんスレ立てありがとうございます。
でもソフトウェア板…

やっちゃったようですなぁ・・・

シロートの思いつきですが、datにgzipでアクセスする代わりに、
あらかじめbbs.cgiが圧縮データを生成して、それを普通にgetしたら
サーバ負荷と転送量の二律背反は緩和されません？
アクセス頻度は書き込み<<読み込みなハズだし、
bbs.cgiも一カキコだけ圧縮してアペンドすれば負荷は小さそうだし。

httpd.confって、それ自体にスクリプト噛ませて、動的に認識させることが出来ましたよね？
特に、Perlディレクティヴかなんかを使えたと思うし、とにかく、夜勤さんに
負担や負荷かけない方法がとりえるんであれば、お願いしてみてもいいかと思いました。
夜勤さんが「出来ない」といっている事情と、こちらがデータそろえて、方法も添えて、
これでいかがでしょう？っていう提案をして、それを天秤に掛けて判断していただくしかないでしょう。

「その方法だと負荷が軽くなる」

という一言だけで、人を動かそうなんてしちゃだめです。
やっぱり、根拠と方法、目論見見積もりがなければ、人の心なんて動きません。

>>923
あーおれってばかだ。ごめんなさい。いますぐいきます。

>>925
gzip圧縮したものに何か追加するには
全部解凍→追加→再圧縮しなくてはならないのです。

>>928
両方生成するとか．．．

>927
つーか本来はソフトウェア板にあって然るべきスレッドだったり。。。

>928
ええ。ですから一レスごとにgzipしたものをアペンドできないかなと。
クライアントも１レスずつ解凍する実装が必要だし、圧縮率はgzip本来の
レベルからは程遠い悲しい物になるかもしれませんけどね。

そうでなく書き込みごとにdatから丸ごと生成するとしても、bbs.cgiが実際に動作する
回数がread.cgiやdatがアクセスされる回数よりも少ないならメリットがあると思います。

ついにソフト板にもかちゅユーザー進出か。
WIN板とまたがって幾つスレ立てれば気が済むんだ。

>929
あ、補足どうもです。
サーバ自体の(html生成の)動作のためにも
今まで通りのdatの生成はしたほうがいいと思います。

>>931
read.cgiが表示するために必ず解凍しなくてはならないとなると
負荷の面で相当厳しいと思われます。

夜勤氏にはあきらめて頑張ってもらう。

これが今夜の結論だな。

>>926
夜勤たんが「できない」って言ってるのは、割に合わないからだろ。
結局金だよ。この問題は。

だいたい全部読んだが、
とりあえず dream 氏はもう少し勉強してくださいという事でしょうか。
http と tcp について。

それと、技術的な方法でツール作者さん達にも手伝ってもらいたい
ならせめて2ch管理側は負荷についての具体的な数値
くらいまとめて出すべきだね。

>>937
つうか、誤爆すんなよ、ってのをまずいうべきなんじゃないの？(笑)

>>926
httpd.confはいじれないって、かなり前から夜勤さんが言ってなかった？

>>939
>>920
ってことなんじゃないの？

>937
他人に「もう少し勉強して下さい」て言っておいて、いいっぱなし？
具体的な数値出せ、っていって、なんの数値が具体的に欲しいのかはいわない？
それはいくらなんでも、かたておち？

>>940
なるほど・・・。
でもさぁ、結局は、夜勤さんの>>314発言を
完全に無視していると捕らえられてもおかしくない意見だよね。

>>942
>>926
素直に読めば理解できないか？話の流れが。

>ええ。ですから一レスごとにgzipしたものをアペンドできないかなと。
そんなことをしたら、圧縮の効果がほとんどなくなりますよ。
実験してみればすぐにでもわかることでしょうに。

>とりあえず dream 氏はもう少し勉強してくださいという事でしょうか。
>http と tcp について。

前も書かれてたと思うけど、彼は事実のとりまとめに徹して、自分の意見を
言う時は名無しになるべきだと思う。正直引き気味

>>943
>>926の話は理解してますってば。
私が言いたいのは、2chの負荷軽減に付いて議論しているこのスレ中で、
夜勤さんは>>314の発言をされているということです。
負荷軽減の効果うんぬんの事を話している場で、httpd.confをいじることを
したくないという意思表示をしていると思われますが？

>>946
>>926を見る限り、Dreamが夜勤さんにやってくれっていっているんじゃなくて、
httpd.confをいじればパフォーマンス良くなるからやれっていうんだったら
それなりの手順用意できるの？っていう話に見えるのは俺だけ？

>>947
ええ、そうなんですが、
最終的に夜勤さんにやってもらうしかない方法であり、かつ、
夜勤さん本人が拒絶している方法(httpd.confいじり)について、
検討していることには変わりないと思いますが？

夜勤さんの意思を尊重するのであれば・・・ね。

>941
申し訳ないですが、言いっぱなしです。
dailup user が云々とか本質的でないこと長々と言ってたり、
自分でツール作ればいくらでも回避できそうな案ばかりだったり、
もうこれはせめて >945 の通り名無しで発言くらいにとどめないと、
読んでるだけでおなかいっぱいですよ。
というわけで >945 氏の意見に ++;

>>645
いや不揮発の馬鹿高いメモリじゃなくて、サーバー飛んだらログ全滅でも
いいからってこと。どうせ飛ぶこと覚悟の負荷隔離鯖だし。

そのそも2chは過去ログ残さなくてもいいような気もする。
現状でも住人が自主的に過去ログサイト立ち上げてる例がいくつかあるし、
2ch側が残さなければより一般的になると思う。
ただ.dat落ち寸前のを拾うためのアクセスが殺到する可能性を考えて
950-1000だけは一定期間読めるようにする等は要るかも。
…過去ログ有料検索とか言ってる現状では期待薄か。

>>944
その通りだけど考え方としては面白いかも、20レスごとくらいにして。
（最大19レスの未圧縮がくっついた圧縮ファイル…ちょっと読み方が
複雑になりそうだが）
どうせブラウザでは読まないし、専用ツール前提ならlzoみたいな軽い圧縮
アルゴリズムも使える。

>>950
それはあなただけの意見です。

<独り言>tcpわかってhttpわかって、ＣでツールかけてPerlかけて、この巨大な
案件すっきりまとめて人望もあって理にかなったことを常に冷静に言える奴って
こんなばかげた話なんかに参加しないよな。</独り言>

念のため、貼っておきます。

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/l50

>>952
ここに書き込んだあなたは・・・。そして私は・・・。
お互い精進しましょ。

HTTP でデータ GET して多少解析して表示するなんてのは
ネットワークプログラミングしたことのある人なら１日も要りません.
技術の話なのに性善説でインターバルなんてのは臍で茶がわきます.
便利に使えるツールにするのは別の話.

>>944
んーそういうことなのか．．．
てっきり、bbs.cgiでdatを生成するときについでに圧縮かけたものも作ってしまえってこと
かと思ってた。

>>955
それJOKESIZE★の方じゃないのか？

>>950
誰が設備投資費をまかなうんでしょ？

>>955
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/l50
こっちで思う存分やってくれ。

>956
両睨みでいいと思います。
一括圧縮ファイルの同時生成なら現在の転送量で負荷削減。
差分圧縮ファイルへの追加なら転送量が増えるけどさらに負荷が下がる。

現実的なのはおそらく前者でしょうね。

>>945が良いことを言った。
正直、司会者としての根性は見上げたものがあるので、その役目に徹してほしい。

>>961
おお、やっぱ皆も思ってたのか。
あの意見のしかたはマジで勘弁して欲しいと思ったり。
頑張って反対してる人もいるけどさぁ…。
そもそもここは議論の場なんだから。

>>961-962
(ﾟдﾟ)ｳﾏｰ

んじゃ、個人的な見解は一切言わないつー事でいきます。
もういいたいことはいったし。
どーせ仕切やなんて、うざがられてナンボですし。ただでさえ。

仕切ってなくてもうざい奴だろうけどな

>>963
いや、そうじゃなく、まとめる場合にそのハンドルにしてほしいんです。
Dream ★ で絞りこめば流れが読めるようにしたいんです。

過去ログを読んでませんが、、、
インターバルをツールに実装すると、patchが出まわるので、
正直者がバカを見ると、、、ソース公開してるツールもありますしね。
んで、サーバで実装するとサーバ負荷が増えるので、
そもそも意味がない。
ということで、IDがあったら巡回できて、
なければ出来ないというのが落としどころになるかと。

>>966
【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/

>>966
夜勤氏を説得しる。
サーバがわの対処で今の数倍のキャパ増大見込めるんだから
それやればいいだけだろーが

早晩破綻しそうだがなｗ

>>968
んだんだ。
ありえねーけど（ｗ

>>958
8月危機の際に既に各鯖１Ｇづつ積んでて大半がディスクキャッシュ
っての読んだ気がする。それをRAMディスクにすれば要らないかと。
ログ消滅の危険性は別の議論として。

>>971
あげんなや。

そういう話は、ソース付けなきゃただのガセ
それから、メモリは欠乏中。vip鯖は512MBでもう足りない。
よく考えてから言ってけれ。相手にされなくなるよ。

>>972
>>529-536 を見る限り、スワップ使ってないんだから、欠乏とはいえないんじゃない?
メモリは欠乏というか、あればあるだけキャッシュもしくはバッファとして
有効活用される。WindowsNT と違って、Unix はメモリをかなり効率よく使ってくれる。

さらにメモリを積めばパフォーマンス良くなるのは認めるけど、
それよりも CPU の負荷を何とかする方が先。

>vip鯖は512MBでもう足りない。
それはあれじゃないかな。apacheとかperlとかの
プロセスが乱立しているからでしょ？

じゃあ、プロセス低減策をとって(read/bbs.cgiが直接Listenして、
selectによる多重化をするとか)その上で、キャッシュデーモンで
オンメモリ処理への道を開くのが王道。

>>974
クズみたいなセキュリティの穴
自前主義は万能とか思ってない？

>>974
apacheより出来が悪いものが完成するに１００ペソ

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/1-10

>>978
埋　め　立　て　屋　死　ん　で　く　だ　さ　い
http://pc.2ch.net/test/read.cgi/software/1016172411/

埋め立てるなと警告しても止めない悪質な奴だからな。

>>979-980
おまえたちもなー

埋め立て屋ってなに？

>>982
地上屋より（略

香取先生見てる？

コイツは埋め立て屋ですか （ｗ
http://kaba.2ch.net/test/read.cgi/sakud/1001476296/984-1000

万能とまでは思っていないが、汎用よりも、
専用のほうがパフォーマンスを稼ぎ易いのは事実。
別にapacheよりも高機能にする必要はない。

>>979-986
埋め立てご苦労！

>>986
いうはやすし。
行うはきよし。

[壁]_・)

>>989
http://www.yomiuri.co.jp/minijiten/23991218.htm

>>990
ワラタ

あ、漏れ仕切り過ぎてたかも…
そうだね　ちょっと反省してる　言いたいこともまだあるけど
これ以上居座ると荒れるだろうから去ることにするよ　みんな
がんばってね　

かちんと来て俺も脊髄反射してたかもね
ゆるしてね
いい夢見ろよ　　　　　
！

かゆければ、かけ。

http://pc.2ch.net/test/read.cgi/software/1017161683/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。