■スレッドリストへ戻る■ 全部 1- 最新50
read.cgi のことについて。
- 1 ：夜勤 ：2001/05/15(火) 23:19
- read.cgi が日増しに呼ばれる回数が増えています。
そんなこんなで 2chのサーバたちも、悲鳴を上げだしています。
そこで、各ソフトの作者さんたちに質問なんですが。
1. どんなときに read.cgi を呼びますか?
2. それは read.cgi を呼ばないで済ませることは出来ますか?
3. そのときに 2ch のサーバ達に機能の修正or追加が必要ですか?皆様の意見をお聞かせください。
- 2 ：夜勤 ：2001/05/15(火) 23:22
- read.cgi は、key が指定され、そのkeyに対応する datがあれば
その dat を読むという動作をします。時には 500K もある dat を
1秒間に数百回読まされるような状況です。とくに巡回機能のあるソフトが
サーバにかなりの負担を掛けているのが現状です。
- 3 ：ヒロユキ＠ギコナビ ：2001/05/16(水) 01:22
- みなさん、お久しぶりです。夜勤さん、はじめまして。うーむ。そんなに負荷が掛かってますか。
最近は、ADSLやらCATVやら高速な環境が増えてきて、受信する量も
多くなってきていることも関係するのかな？
ギコナビは、read.cgiを読んでいません。dat直読みです。
でも、これでも負荷を掛けるのには変わりはないですが。ところで、どうやって解決しようかとかより、なんでこの問題が
起こるのかという議論のほうがいいような気がします。＃とりあえず、想定できる問題やら質問やら、ゴチャゴチャかきます。
・巡回機能で、沢山のスレをダウンロードしまくっている人がいるので、負荷がすごい？
・read.cgiの中で負荷が掛かる部分がある？
・そもそも、人が来すぎ？
・意味の無いリロードを繰り返す人がいる？
・現在のdat構造は、効率が悪い？
・検索エンジンの巡回でも負荷が掛かっている？
・（パールはシロートなので分からんけど）cgiの実行環境で解決できる部分は無いのか？
＃たとえば、毎回プロセスを起動せずに済む方法は？とか。もっともっと、いっぱいあるなー。って振っておくだけ振っておいて、僕は寝ます。ﾈﾑｰなんだもん。
- 4 ：ふみもたたけし ：2001/05/16(水) 21:44
- スレ一覧を毎回全取得するのは明らかに無駄だよね。
通常は上位50-100、リロード間隔によっては
20-30程度で十分つじつまが合いそう。>とくに巡回機能のあるソフトが
>サーバにかなりの負担を掛けているのが...
Short Cutsでは巡回ではなく更新チェックのみにとどめる予定。
# 新着数はスレ一覧から算出できるし、
# そもそもofflineという状態を想定していないので。スレ違いだけど
subject.txt,datの形式をCSVに統一は難しいですか？ >夜勤さん
# できればデータの配置順序も
Delphiだとコードが複雑になってしまうし、
スクリプトの変更に対応するのも大変そうなので。
- 5 ：かちゅ〜しゃ作者 ：2001/05/16(水) 23:37
- 夜勤さん、ご苦労様です。
えっと、とりあえずは「かちゅ〜しゃ」の動作についてだけ。A.1
Version2以降では、基本的にdatから直接取得してます。
CGIを呼び出すのは、最新レス50件モードの時か、
レス内の範囲指定付きリンクをクリックした時だけです。
またVer2から巡回機能を付けましたが、これも直接dat読みです。A.2
ちょこっとだけ機能を削ることになりますが、
read.cgiを全く呼び出さなくても充分な機能は保てると思いますので、
次からは書き込み以外CGIに触らない方向でいきたいです。A.3
ふみもたたけしさんも言われているように、
subject.txtや*.datの形式を統一していただけるとありがたいです。おやすみなさい。
- 6 ：Dax ：2001/05/17(木) 08:28
- 夜勤さん、こんにちは。
モナヂラでつくってるツール全部がDAT直読みなので read.cgiの件は
あまりお役に立てそうに無いです。シクシク、、 >とくに巡回機能のあるソフトが
>サーバにかなりの負担を掛けているのが...
これがどのソフトか分かれば話は早いんですけどね。
>subject.txt,datの形式をCSVに統一は難しいですか？
CSVじゃなくてもいいので何か統一してほしいですね。DATの形式を途中で変更されるとローカルのログを
いったん削除して再度全取得になるのでサーバーに
かなり負荷がかかると思います。(最近の負荷はこれが原因かも？) >ところで、どうやって解決しようかとかより、なんでこの問題が
>起こるのかという議論のほうがいいような気がします。
原因追究はやっぱり難しいのかなー、
DAT形式変更による全再取得をか read.cgiツールユーザーが一気に
行ったのが原因かとも思ったんですが、、予想ですけどね。#read.cgiを呼ばない２ちゃんねるに優しい(?)モナヂラ製ソフトを
#使ってもらえるように努力しなければ・・・
- 7 ：一 五明 ：2001/05/17(木) 15:09
- 今作ってるINCMプラグは、とりあえず単一スレッドの巡回のみ考えてます。
この場合、read.cgiに触れないことは一応可能です。 ただし、初回は行数を数えて発言No.にするので、全部読み込む必要があります。
.datのサイズによっては「初回だけread.cgi」のほうがましなのかも知れません。 あと、削除でポインタ見失ったときのリカバリ処理は、運が悪いと何度も
リクエスト掛けたり重複転送が発生したりで、下手すりゃread.cgiより負荷が
上がるかも知れません。
特にHTTP1.1の仕様上、.datが縮んでしまって.datサイズより大きな値をRange:で
指定してしまうと最初から全部返って来る(泣)ので、例え素早くshutdown掛けても
サーバー側のバッファメモリは結構食うのかも。
- 8 ：一 五明 ：2001/05/17(木) 15:11
- あったら助かると思うのはサーバー監視所に書いた「.datと同名の.ptrファイルに
50書込程度毎にファイルポインタを記述」です。→ http://green.jbbs.net/computer/bbs/read.cgi?BBS=20&KEY=989476151&START=175&END=176&NOFIRST=TRUE あと、.dat中の各行に書込No.が有れば、リカバリしやすいですね。
転送量は増えますが… 他には、各スレッドの最新レス50（100）をHTMLにしておけば、ブラウザからの
read.cgi呼び出し回数も減ると思うし、巡回ツールのポインタリカバリにも使えて
便利…と言うのも駄目でしょうか？(^^;
- 9 ：一 五明 ：2001/05/17(木) 15:14
- .datに、各パラメーターの区切りが「,」のと「<>」のがあるのは確認
しましたが、形式変更というのはこれでしょうか？
これのことなら今作ってるのは行単位で自動判別しますので混在でもok
です。
- 10 ：Dax ：2001/05/17(木) 15:52
- >形式変更というのはこれでしょうか？
そうです。
カンマ区切りだった DAT が途中で <> 区切りになると
ファイルサイズが変わってしまい差分取得に失敗するんです。
あぼーんの時と似た現象です。
一 五明さんのプラグインはあぼーん検出ロジックがあるようなので
あんまり問題にはならないかな？
- 11 ：名無しさん ：2001/05/17(木) 18:16
- いっそのこと100レスごとに
ファイルばらしちゃえばいいんじゃない？
- 12 ：一 五明 ：2001/05/17(木) 20:26
- >>6
大丈夫で、他の汎用の巡回ツール方面と話し合ったほうが負荷軽減には
有効かも知れませんね(^^;
\
- 13 ：一 五明 ：2001/05/17(木) 20:34
- >>12
すみません書き込みミスです(^^; monazillaは元々2ch運営に協力的ですから、ある意味放っておいても
大丈夫で、他の汎用の巡回ツール方面と話し合ったほうが負荷軽減には
有効かも知れませんね…と書こうとしました。
- 14 ：一 五明 ：2001/05/17(木) 20:42
- >>9
よく考えたらDelphi等の環境を考えてない発言で済みませんでした。
（Perlだと手間かからないもので…）
汎用性のある形式にしておけば、2ch以外の掲示板でも同形式を採用
して（よくある？2ch互換掲示板じゃなくて、見た目は全く別物でも
.datの形式だけ同じというもの）2ch用のツールが使えることを考慮
するような動きが出てくるかも??>>10
ロジックが完成すれば問題無いんですが、完成しないかも（おいおい）。
実際思ったより大変…
- 15 ：夜勤 ：2001/05/18(金) 00:18
- 区切りの方は、たぶん <> に統一されるのだと思います。
piza , yasai , salad と来ましたので、
ただ bbs.cgi とかは、当方の触れませんので、.ptrを作るとかは、ひろゆきさんに
やってもらうしかありませんが、「今世紀中にはなんとか・・・」とか言われそうです。
今回は read.cgi の改造等しか出来ませんのです。(すんません)サーバの与える負荷は dat を直接読んでいただくのが極端に小さいです。
read.cgi を毎回起動するということもありますし、データ量もかなり read.cgi
経由では増えてしまいます。(htmlタグの分)
- 16 ：2chブラウザ作者 ：2001/05/18(金) 01:15
- 1.範囲指定でレスをとりたいとき
2.難しいかも（最新30とか）
3.わからんです
datのPartial Getでできないことはないでしょうけど、
無駄なリクエストが増えそうです。
あぼーんでログが詰まるのは、数百バイト前から読み直して
パターンマッチで頭出しできないこともないですが、
嵐で同じレスが同時刻にかかれてたりすると、区別の
パターンマッチにも失敗しそうです。まぁ、これは極端
な事例なので、たいていは頭出しできそうですね。
それを考えると、datにレス番を加えるってのがいいかも。
でもこれだと、datのフォーマットが変わるので面倒ですね。間とって（？）read.cgiにHTMLを生成せず、指定されたレスの
dat行を返すモードをつけるってのはどうでしょうか。
read.cgiの高負荷になっているところとして、
1.スクリプトの読み込み、中間コードへのコンパイル
2.読み込み
3.行の切り出し
4.CGIパラメータの解釈
5.HTML生成
とあると思いますが、HTMLを生成しなければ5はキャンセルできそうです。
1はmod_perl使ってれば関係ないだろうけど、2,3が結構きついんでしょうか。あと、私は古い2chスクリプトしか見たことないんですが、その中では
s/正規表現/置換文字列/のところで、oフラグが使われていませんでした。
これはなぜなのでしょうか？
oをつけると、正規表現のコンパイルが最初の1回だけになるので、
スクリプトによっては（正規表現マッチをループで大量にまわすようなもの）
劇的に負荷が下がることがあります。
もちろん、その特性上、正規表現中に変数が含まれていて、実行時に
変化するような場合には使えませんが。
- 17 ：一 五明 ：2001/05/18(金) 10:03
- >>15
>ただ bbs.cgi とかは、当方の触れませんので、.ptrを作るとかは、ひろゆきさんに これは、書き込み時でなくても、読み出し時にキャッシュのような意味合いで
作れると思います。 ・.datより.ptrのタイムスタンプが古かったら今まで通り.datの頭から
読み出して、ついでに.ptr作成
・.ptrのほうが新しかったら、.ptrを利用して.datを途中から読む …でも、書き込みより読み出しの頻度がずっと大きいので、かなりの確率で高速化
出来そうな気がします。
（Unixのパーミッション辺りは詳しくないのですが）read.cgiにはファイルの書き
込み権限自体が与えられてなくて読むしか出来なかったりだと無理でしょうが…
- 18 ：夜勤 ：2001/05/18(金) 22:22
- read.cgi は、Cで書かれています。
頑張っていろいろ最適化を行い、かなり改良したのですが、この辺が限界かと、、、一番重いと思われるのは、read.cgiの起動 と .dat ファイルの読み込みです。
とにかくファイルの open,close を少しでも減らしたいです。また、一日に30,000
スレッド位新規に立ち、総計数えられないほどのスレッドが live です。
.ptr を作りかつ管理するのは、さらに渋滞を招きますし HD の容量も有限です。.datの転送であれば、apacheがやってくれるので、かなり負荷は減ります。
だいたい１サーバで read.cgiは、ピーク時に 1,000/sec くらい呼ばれています。
- 19 ：一 五明 ：2001/05/19(土) 06:57
- いろいろ難しいですね…。
そう言や参考になるかどうかは不明ですが、こんなとこも。 → http://nh.mikage.to/test/read.cgi?bbs=discuss&key=983979360
- 20 ：夜勤 ：2001/05/19(土) 23:08
- だいたい一台あたりピーク時で 12〜15Mbps です。
- 21 ：名無しさん ：2001/05/20(日) 15:34
- まだ、apacheのモヂュールにしてしまう(mod_read?)が残ってまっせ(笑)
それはそうと、read.cgiで蹴って強制的にDAT直読みに移行させるという
のも、悪くない手だと思いますよ。ちゃんとエラーメッセージさえだせば。
かちゅ〜しゃも、まだDAT読みしないβ12使っている人、多いみたいだし。
- 22 ：Dax ：2001/05/21(月) 23:49
- Apacheモジュールってアパッチのインプロセスで動くようなもんですかね？
だとしたらCGI起動にかかる時間はクリアできそうですね。
Kylixもリリースされたことだし、試す価値あり？？>それを考えると、datにレス番を加えるってのがいいかも。
それいいですね。<1>名無しさん<>sage<>2001/04/01<>コメント<>
こんな感じなら既存のロジックでも互換は保てますよね、
- 23 ：16 ：2001/05/25(金) 01:16
- >>18
これを読む限り、あとはPostgreSQLなり、MySQLなりを
バックエンドに置くしかなさそう。
FileSystemをRaiserFSにすればi-nodeの検索（i.e.ファイルオープン）
は多少速くなるかな？ 読み込みはext2と同じか遅めらしいですが。
dat読みにしても、apacheはdatをopen、closeするでしょうから、
高負荷プロセスがapacheかread.cgiかの違いだけではないでしょうか。
readcgiの起動に関しては、>>21さんの通りですね。
純粋にopen,closeを減らすということであれば、テレホタイムの
50、100レス制限解除ですかね。でも、これは副作用が大きすぎるので
論外でしょうが。
- 24 ：21 ：2001/05/25(金) 13:32
- >>18
あとは馬鹿みたい(GB単位)にメモリを積んで、主要なスレをオンメモリで
処理するという奥の手がありますが。
平均的スレサイズを100KBとみて、1GBで10000スレです。だいたい１板で
200もアクティブなスレはないと思われますので、50以上の板が捌けることに。
今はメモリもやすいので、お得です(笑)ところで、よけいなお世話かもしれませんが、piza鯖にお話すると、
Server: Apache/1.3.6 (Unix) PHP/4.0.3pl1 mod_ssl/2.3.6 OpenSSL/0.9.3
という返事がきました。いらないmodule(mod_sslとか)は外すべきかと思います。
- 25 ：夜勤 ：2001/05/26(土) 21:05
- メモリ既に 1G づつ積んでいます。ほぼオンメモリ状態で処理されていると思います。
ちなみに書くサーバごとのスレッド数ですが、
調べてみました。http://green.jbbs.net/computer/bbs/read.cgi?BBS=20&KEY=981877272&START=43&END=43&NOFIRST=TRUE
- 26 ：フッサール少佐 ：2001/05/27(日) 00:23
- Servletはどうでしょ？
CGIをプロセス起動してるんだと思いますが、Servletなら自動的にスレッド
の起動になりますから結構軽いと思いますよ。つーか、パフォーマンスの問題はまず何が一番ネックになっているかでしょうね。
それによって対策が変わってきます。
- 27 ：21 ：2001/05/29(火) 05:19
- >>25
それは、大体のファイルがキャッシュされてるってことですよね。
私が言いたいのは、2ch処理用常設プロセスがあって、HTTP応答、
投稿処理など全部を同じプロセス内共有メモリで行うってことです。
スレデータはメモリにずっと居座り続けるわけです。
＃ディスクへの書き込みは、基本的にはバックアップの意味でしかしなく、
＃メモリが足りなくなったら、更新してないスレをディスク送りにするだけ。
だから、ある意味もっとも完結していて(汎用性が無い)、究極。
- 28 ：名無しさん ：2001/05/29(火) 08:25
- 負荷が増えた理由は、主に
・高速回線の普及
・過去ログが検索エンジンからリンクされるようになり人が増えた
・新入社員/新入生の季節で人が増えた
といったところだと思います。で、ツール側から対応できる最大の努力は、
「必ずIf-Modified-Sinceを付ける(当然dat直読みで差分取得)」でしょう。
これにより、HTTPdが読むのはディレクトリ一覧(大抵キャッシュ上？)のみとなり、
未更新ならば殆ど負担にならないと思います。実際に「subject取得後、connectしたままでの上位数十件の差分取得」を
テレホタイム等に行い、レスポンスをみると
更新されていないdatの取得が連続している間は、
サーバーに待たされる事はまず無いです。それに対して、sageレス等で
途中に僅かでもデータの転送が含まれると、そこで待たされる事があります。
単純に推測すると、Not Modifiedを返す時はディレクトリを読むだけで
ファイルを開かずに済むからだと思います。レスポンスが遅い＝負荷が高いと単純には決めつけられないかもしれませんが、
単純に「すぐ処理が終わる」だけでも多少は意味があるでしょう。
特に「あまり更新されないけど、一応巡回しているスレ」が多数ある場合、
それなりには効果があるはずです。
- 29 ：名無しさん ：2001/05/29(火) 08:26
- read.cgi側の工夫としては、レスポンスヘッダに
datの更新日付をLast-Modifiedとして付加するのはどうでしょう？
CGIやHTTPdの事は全然知らないのですが、
もし、read.cgiのレスポンスにLast-Modifiedを付加できるならば、
巡回ツールによっては「If-Modified-Since」を付けてくれているかもしれません。
(URL更新チェックのみの巡回ソフトもありますし)
また、ブラウザの取得の仕組みも知りませんが、
ブラウザが更新チェックをHEADメソッドで行っているとしたら、
REQUEST_METHODがHEADの場合には、ファイルを開かずに更新日時のみを取得し
Last-Modified付きのヘッダを返せば、
ブラウザはキャッシュから読んでくれる気もします。
(でも、ブラウザ以外の2ch巡回ツールでread.cgiを呼ぶ場合は無視されそうです)まあ、これらは全て「ファイルI/Oがボトルネック」の場合だけで、
「CGIプロセスの多さがボトルネック」の場合は、
他の手段を考えないと解決にはなりませんが。
- 30 ：夜勤 ：2001/05/30(水) 17:42
- 更新があったか、なかったかを常時観察するために read.cgi が呼ばれていて
key付きで read.cgi が呼ばれた場合は、必ずdat読み->html化->吐き出し
という処理が動きます。この更新の有無の確認のためにread.cgiを使うというのが避けれれば
かなりサーバが楽になるように思えるのですが、いかがでしょうか?
- 31 ：28 ：2001/05/31(木) 01:24
- mentaiを圧縮したようですが、dat/にあるファイル数は
負荷にどの程度の影響を与えるのでしょう？
非常に感覚的ですが、去年の７月位に「転送量を減らしたい」という理由で
テレホタイムの100レス制限やロビーの10スレ制限が出来たときは、
あまり軽くなったとは感じませんでした。
それに対し、９月位にpizaやmentaiで圧縮した直後は
すごく軽くなったような気がしたのを覚えています。
これが気のせいでなければ、
過去ログの圧縮でbbs.cgiの中でsubject.txtを並べ替える部分か、
ディレクトリ内でinodeを検索する部分か、
どちらかが結構大きな負荷になっていたと思います。負荷増大には2ch用ブラウザの普及も関係しているでしょう。
読み易いというのもあるけど、書きこみ易い(早い)というのが
書きこみを増やし、結果として負荷につながっていると思います。
(夜勤さんはそれがわかっているから、スレを立てたんでしょうけど)
利用者数からすると、やっぱりかちゅ〜しゃなんでしょうか。
read.cgiを呼び出す回数は、古いバージョンを使っている人や
最新50レス取得モードで利用している人が結構多そうだし、
ls=nnの付いたスレへのリンクにジャンプする場合を含めかなりありそうです。
dat取得時でも、差分チェック(巡回)が必ず最後の改行を
転送している(らしい)のもサーバーにはきつそうです。
(１バイトのためにファイルを開かなければいけない)でも、忙しい作者さんをせかすわけにもいかないし、
そもそも、まだまだ人は増えると思われるので、
CGIをやめる等、根本的に解決しなければいけない気もします。
- 32 ：28 ：2001/05/31(木) 01:24
- で、Last-Modified関係をもう少しだけ調べてみました。
リクエストに対して、CGI側でレスポンスにLast-Modifiedを付加すれば、
ブラウザは次回のリクエストにIf-Modified-Sinceを付加してGETするようです。
なので、ブラウザからのリクエストに関しては
HTTP_IF_MODIFIED_SINCEを調べ、stat()で得た日付と比較して
更新されていなければ、"Status: 304 Not Modified"を返すことにすれば、
datファイルをオープンする負荷(とネットワーク負荷)は減らせるでしょう。
逆にいえば、read.cgi側でLast-Modifiedを付加したのに
次回もIf-Modified-Sinceを付けずに毎回全部GETするUserAgentは、
サーバー/ネットワークリソースを無駄使いし、マナーが悪いともいえます。というのが建前だったんですが、実は手元で試したAnHTTPdでは
HTTP_IF_MODIFIED_SINCEが得られず焦りました。(Apache入れてない)
でも、同じような事を考えている人はたくさんいるようで、
googleで検索して、こんなログもありました。
http://tohoho.wakusei.ne.jp/lng/200001/00010426.htm
ここによれば、Apache1.3なら取得できる感じです。(すいません未確認)
もし、ApacheだけでNotModifiedを判断してしまうならダメダメですが、
Apacheがリクエストをそのままread.cgiに渡し、read.cgiが304を返す形に出来るなら
考慮しても良いと思います。(Apacheの設定があるかもしれません)
あと、ヒットしたページはずっと沢山あったので、
丁寧に解説しているページもあるかと思います。感覚的には
Last-Modified付加 → ネットワーク負荷の減少
HTTP_IF_MODIFIED_SINCEをチェック → ファイルI/O負荷の減少
という効果がありそうです。
read.cgi Ver4はCで書かれているとの事なので、
stat(),time(),gmtime(),strftime()を適当に組み合わせれば
ファイル更新日の取得やLast-Modifiedの出力も難しくないと思います。
というか、そこまでやっても負荷が減らなければ、
read.cgi側から出来る事はもう残っていないでしょう。
サーバー増設以外には、ツール側の努力を待つのと、
Servlet等別な手段を考えるしかないと思います。
あるいは究極の選択「HTTPdを自前で作成」「2ch閉鎖」ですか。
- 33 ：一 五明 ：2001/05/31(木) 07:26
- >>31
>負荷増大には2ch用ブラウザの普及も関係しているでしょう。
>読み易いというのもあるけど、書きこみ易い(早い)というのが
>書きこみを増やし、結果として負荷につながっていると思います。 １リクエストで複数書き込みを（間に「&multipart=&」とでも挟んで）
送信出来るモードがあれば便利かつ負荷減少にも繋がると思うんですけど
ね…その際合計サイズの上限は決めておいたほうがいいと思いますが。
- 34 ：ＤｏｌＢａｃｋｙ ：2001/05/31(木) 14:50
- Last-Modifiedを吐くのはCでもPerlでも簡単だと思うんだけど、
I/Oを最小限に抑えるにはLast-Modifiedを吐く専用のモードを作った方がよいのだろうか。。。↓Perlで無理矢理まとめると２行。。。
my @TIME = gmtime(time);
print 'Last-Modified: ' . sprintf("%s, %02d %s %d %02d:%02d:%02d GMT",('Sun','Mon','Tue','Wed','Thu','Fri','Sat')[$TIME[6]],$TIME[3],('Jan','Feb','Mar','Apr','May','Jun','Jul','Aug','Sep','Oct','Nov','Dec')[$TIME[4]],$TIME[5] + 1900, @TIME[2,1,0]) . "\nContent-type: text/plain\n\nヽ(´ー`)ﾉ";
- 35 ：ghanyan ：2001/05/31(木) 17:26
- >>34
専用のモードがいるのは、むしろIf-Modified-Sinceを判断する部分だと思われ。
でも、とりあえず、対抗すてみたり(笑)
Cではstrftimeがあるから、実質一行。(昔書いた、statを使う奴)
struct stat fdata; char tmp[256];
if( stat(filename,&fdata) != 0)
{return -1;}
strftime(tmp,255,"Last-Modified: %a, %d %b %Y %H:%M:%S GMT\n",
gmtime(&fdata.st_mtimespec.tv_sec) );perlに標準でstrftimeが無いのは不思議。(POSIXとかにあったとおもう)
ま、perlでも、RFC2068の厚意に甘えて
print 'Last-Modified: ', scalar gmtime time, '\n';
という手がありますが(asctime形式)。昔実験したら、apacheが変換してくれた記憶があります。
- 36 ：28 ：2001/05/31(木) 23:17
- すいません、勘違いしていました。
ブラウザは、レスポンスにLast-Modifiedが無くても、
Date:の日時を元にIf-Modified-Sinceを付けてGETするようです。
だから、CGI側でLast-Modifiedを付加する利点は、
Apache(1.3以降？)が判断してNotModifiedを返してくれる事、
次回のIf-Modified-Sinceに与えられる日付を指定出来る事、です。加えて、あれから、read.cgiが時間帯によって２種類のHTMLを
出力しているという非常に大きな問題に気付きました。
単純にLast-Modifiedを付加するだけだと、
とても簡単にネットワーク負荷を減らせるのですが、
dat更新後に最初にアクセスした時間帯によって
以後更新されるまでずっと見え方が制限されることになります。気しないというのも手ではあるものの、あまり良い手とは思えません。
何とか切りぬける道はありそうですが、きれいに解決するには
やはりCGI側で更新チェックを行いStatusを返す方がよさそうです。
この場合にはローカルにキャッシュされているHTMLの出力時刻を
知る必要があるため、Dateだけに従ったほうがいいかもしれません。
現状では自殺行為ですが、テレホ制限を外してHTMLを１種類に出来れば
一番簡単だし理想的です。
(もちろん、read.cgiの呼出が減る方がさらに理想的)
- 37 ：ＤｏｌＢａｃｋｙ ：2001/06/01(金) 19:49
- ちなみに今や化石（？）のブラウザ、OFF-LAW-WINのログ取得処理。
１・サブジェクト読み
２・DAT直接参照でHTTP応答ヘッダを取得
３・応答ヘッダのContent-Lengthを既存ファイルと比較して差分を取得
ログ全取得の条件は「既存ファイルがないOR既存ファイルよりContent-Lengthが小さいこと」です。
read.cgiを介してしまうと、（いくらcgiを改良しようと）プロセスがメモりを喰っちゃうと思ったんで、それは避けました。
そんな感じです。
- 38 ：名無しさん ：2001/06/08(金) 11:57
- 2ch専用ブラウザーの作者がたくさん見ていそうなのでこっちでも話振っときます。
新スクリプトのbbs.cgiは,→ , の変換と、本文の & → & の変換を
行わないようになってるので、各ブラウザーもそれに合わせて区切りが <> のとき
には変換を行わないようにしてほしいです。詳しくはこっち↓
http://corn.2ch.net/test/read.cgi?bbs=entrance&key=991902157&st=16
- 39 ：名無しさん ：2001/06/08(金) 11:58
- あ、変換されてる。＠｀→ , と書きたかったと思いねえ。
- 40 ：名無しさん ：2001/08/11(土) 05:32
- 【ebi＆curry鯖重過ぎます Part2】
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=997196349ゴミレスばかりですが、何らかの参考になるでしょうか。
かなりまずい状況のようです。
- 41 ：委員長 ：2001/08/11(土) 11:45
- 一応全スレ読みました。
基本的にここで紹介されているブラウザツールはread.cgiを触ってないんぢゃ
ないかな？
どちらかと言うと、「2ちゃんねる」に優しいツールというか(笑)。ところで、時折夜勤さんが話題に上げる巡回機能についてなんですが、アレって
サーバーへの負荷は多大な物なんですかね？
datの差分読み込みで巡回しているという前提なら、巡回であっても通常のクリック
やダブルクリックによる閲覧であっても、お気に入りスレッドは全部読むのなら
変わりはないんぢゃないかなぁと思うんですけど。
お気に入りに100スレくらい登録してあって、巡回なら100スレッド絶対に
巡回しちゃうけど、手動なら50スレくらい読んだところでやめるかもしれん
という理屈はありだけど(笑)。
- 42 ：委員長 ：2001/08/11(土) 11:46
- あと、気になるのがbbs.cgiですね。
こいつは書き込み機能をつける為には絶対に触らねばならない訳ですが、
最近書き込まれる前に1クッション入れて、ツールからは書き込み出来ないサーバが
あるらしいですね。(すんません、聞いた話で確認はしてない)
「ツールからの書き込み対策か？」なんていう話を聞きましたが。
狙いは判りませんが、アレはどうなんだろ？
そういうサーバの場合、通常のブラウザから書き込みをせざるを得ない訳で、逆に通常の
ブラウザがread.cgiを呼び出す事になるし、サーバへの負荷は圧倒的に増える方向に
働く事になると思うんだけどなぁ。
ちょっとその辺を話題にしたスレッドでも開いてみるか。
- 43 ：委員長 ：2001/08/11(土) 12:18
- あれ？違うか。
1クッション入ってしまうから出来ないのは、レス書きではなくて、
スレッド立ての方か。
申し訳ない、>>42 は忘れて下さい。
(やっぱ、確認せずに書いちゃイカンな)
- 44 ：名無しさん ：2001/08/11(土) 13:22
- これですね。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=997196349&st=506&to=506&nofirst=true>前向きに考えると、今いろいろな２ちゃんねる閲覧ツールが
>出ていますが、(私も使っています)。その作者の方々が操作性
>とかスピードに主眼を置いている力の少しを、この問題に注いで
>くれたりしたらかなり助かるかも・・・
>
>極力サーバのCPUではなく各クライアントのCPUを使う。
>転送量が最低になるような最適化をする。
>
>今一番こまっているのが、前からちらちらとお話しているんですが、
>read.cgi の呼び出しなんですよ。スレッドの更新があったかどうか
>の判定とか、、、
>このへんに気を使ったツールが普及するとかなり効果があるかと、
- 45 ：名無しさん ：2001/08/11(土) 13:23
- これですね。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=997196349&st=506&to=506&nofirst=true>前向きに考えると、今いろいろな２ちゃんねる閲覧ツールが
>出ていますが、(私も使っています)。その作者の方々が操作性
>とかスピードに主眼を置いている力の少しを、この問題に注いで
>くれたりしたらかなり助かるかも・・・
>
>極力サーバのCPUではなく各クライアントのCPUを使う。
>転送量が最低になるような最適化をする。
>
>今一番こまっているのが、前からちらちらとお話しているんですが、
>read.cgi の呼び出しなんですよ。スレッドの更新があったかどうか
>の判定とか、、、
>このへんに気を使ったツールが普及するとかなり効果があるかと、
- 46 ：Dax ：2001/08/15(水) 23:16
- >>41
＞ところで、時折夜勤さんが話題に上げる巡回機能についてなんですが、アレって
＞サーバーへの負荷は多大な物なんですかね？どっかに書き込みがあったんですがやっぱ負荷は結構あるみたいです。
で、いろいろ考えたんですがモナヂラで開発者向けのガイドラインを
つくってはどうかと。例えばレス取得時に read.cgi を呼ばないとか、
お気に入りの巡回にかちゅ〜しゃのような時間制限を必ずつけるとか。
- 47 ：委員長 ：2001/08/16(木) 11:36
- >>46
> で、いろいろ考えたんですがモナヂラで開発者向けのガイドラインを
> つくってはどうかと。いいっすね。
モナヂラとしてのスタンスってのはあっても良いかと。
あと私が思う事は、「2ちゃんねる」自体はこういうツールを
どう思ってるのかな？と。
広告バナー辺りを考えると、否定的なのか？
サーバの負荷を考慮して、肯定的なのか？
モナヂラと2ちゃんねるとの間で、その辺の意見交換が行われると
良いなと思うのですが、出来ませんかね？
- 48 ：ghanyan ：2001/08/16(木) 15:38
- 上位20件のConnection: Keep-Aliveによるdat大量強奪機能を備えている
ぎこはにゃ〜んは、ちょっとまずいかな？
次回は自動更新機能あたりをつけようか、とか。donutにはその機能があるから、
cgi経由で自動更新するよりはましかも、等と思っていたりしますが‥‥
- 49 ：委員長 ：2001/08/16(木) 18:13
- もうご存知だと思いますが、サーバー負荷の低減の一環として、
ebiサーバとcurryサーバで >>1 機能を停止してます。
どうやら実験的なようですが、最近のサーバ負荷はシャレにならない状況
らしく、その対応策の一環のようです。
確かにこの対応だと、リンクタグの生成ルーティンと、タグの分だけ転送量を
削減出来るので、それなりに成果は期待出来そうですな。
私的にはこの対応は、2ちゃんねるブラウザの普及にも繋がるのではないかと
思いますし、良い事だと思ってます。基本的に今までは、>>1 機能に関してはポップアップ機能の実装だけで済んだ
のですが、今後は >>1 を検出してタグを生成するルーティンが必要になります
ね。
>>1 機能は有効で、後半から無効に
なってます。
つまり、>>1 を検出してタグを生成するのではなく、>>1 を検出後、タグが付
いていないかどうか判定して、タグが無ければ生成するというルーティンが必要
になります。
- 50 ：ヒロユキ＠ギコナビ ：2001/08/18(土) 19:27
- ＞確かにこの対応だと、リンクタグの生成ルーティンと、タグの分だけ転送量を
＞削減出来るので、それなりに成果は期待出来そうですな。
転送量については効果は期待できると思います。
あとhttp://リンクをread.cgiではなくて、bbs.cgiでやるなどの変更もしたほうが
いいような・・・。
- 51 ：ヒロユキ＠ギコナビ ：2001/08/18(土) 20:22
- と、思っていたら、すでにhttpリンクはdatに書き込まれていますね。
- 52 ：ヒロユキ＠ギコナビ ：2001/08/18(土) 20:37
- ごめん、>>51はウソでした。
httpリンクは書き込まれていません。
- 53 ：ヒロユキ＠ギコナビ ：2001/08/18(土) 20:39
- なんどもすみません。
>>52がウソでした。
新スクリプトpiza2とかは、通常のhttpリンクが書き込み時にタグが付加されます。
- 54 ：名無しさん ：2001/08/24(金) 22:47
- PINK鯖read.cgiからしか読めないのなんとかしてー
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998658340&ls=50
- 55 ：名無しさん ：2001/08/24(金) 23:21
- なんとかなったー
- 56 ：委員長 ：2001/09/01(土) 23:02
- このスレでいいのうかな？
gzip対応の方法として一例をあげときます。
Tar32.DLLを使うと展開出来ますね。
Tar32.DLLをそのまま使う手法だとユーザーの環境にTar32.DLLが必要に
なるので、同封されているtar32.libを使うとよいですね。
この方法だと、一旦ファイルに保存したgzipのデータを変数に直接放り込めます。
BCBでツールを作る場合はこの方法も良さそうです。
リクエストがあれば、具体的な方法を書きますが、いります？
- 57 ：委員長 ：2001/09/01(土) 23:08
- あと、ご存知かもしれませんが、AcceptEncodingにgzipを入れていると、
http://www2.bbspink.com/club/subject.txtはgzipで返ってきますね。
datデータは非圧縮で返ってきますが。
今のところ圧縮されて返って来るのは、これだけかな？
情報をお持ちの方、教えて下さいな。
- 58 ：jtelaz ：2001/09/02(日) 09:42
- http://teri.2ch.net/test/read.cgi?bbs=accuse&key=999345252&st=764&to=764どうやら全サーバにmod_gzipが入るみたいですよ
- 59 ：名無しさん ：2001/09/07(金) 16:21
- プログラム板のmonazillaスレにも貼りましたがこっちにも。267 名前：名無しさんの声 投稿日：01/09/07 13:52 ID:zl1Zgn4M
bbspinkのdatを圧縮可能にする予定はありませんか?
ツールが対応すればかなりの節約になると思います。
>>267
予定はありありです。
実験してみたいのですが、、、、、
ツールの作者の方々に、組み込んでいただかないと、 入れてみようかしら?
でも、転送量の観察をしたいので、ツールが組み込んだら、
教えてもらいたかったりします。
- 60 ：ghanyan ：2001/09/09(日) 05:19
- ぎこはにゃ〜んは対応済みです。 bbspinkのsubject.txtが圧縮されて
送られていましたが、特に誤動作した様子は見られませんので。http://www.geocities.com/ghanyan/latest/ にあるソースで、
mona/http/gzip.cppは、ストリームで解凍するときや、zlibでgzip解凍
するときに役立つかもしれません。
mona.exeの実行後出力される、./out.txtはhttp応答のログなので、
本当にgzipで送られてきているのか確かめられて、便利なかもしれません。
- 61 ：Dax ：2001/09/14(金) 22:42
- 夜勤さんが新スクリプト実験場をつくってます。愛の種
http://ex.2ch.net/ainotane/
- 62 ：名無しさん ：2001/10/13(土) 01:29
- JBBSのread.cgiでrawモードみたいな奴があった気がするんですが、
どういうオプションを指定すればいいのでしょう？いろいろ探してみたのですが、
見つけることができませんでした。どなたか教えてください。。
- 63 ：名無しさん ：2001/10/13(土) 18:17
- たぶんmono氏のJBBSコンバータを参考にすると委員では
http://www.raiji.com/cgiscript/
- 64 ：名無しさん ：2001/10/13(土) 22:10
- offlaw.cgi?
- 65 ：名無しさん ：2001/10/13(土) 22:58
- レスありがとうございます！＞63,64
read.cgiのオプション、、って思いっきり勘違いしてましたね(w＞自分JBBS対応ブラウザ作ってる作者さん達はofflaw.cgi使ってるのかな？
それともread.cgi？自分もJBBS対応ブラウザ作ろうかな〜とか思ってるのですが、、
- 66 ：Dax ：2001/10/17(水) 21:01
- >65
私は read.cgi 使ってます。offlaw.cgiのこと知らなかったんで。。
JBBS対応ブラウザの開発、がんばってください。
- 67 ：名無しさん ：2001/10/29(月) 00:03
- 17氏のなんちゃってJBBSスクリプトを使っているんですけど
ほとんどのブラウザで見れないっす．．．．
アドレスでJBBSを判断しているんですかねぇ．．．
- 68 ：名無しさん ：2001/10/29(月) 15:14
- 17さんのって２ちゃんねる互換じゃなかったっけ？
JBBS互換もできたのかな？？
- 69 ：67 ：2001/10/29(月) 18:26
- >>68
知っている人は知っていると思うけど、bbs1.zipです。
- 70 ：名無しさん ：2001/11/01(木) 17:37
- >>67
www.jbbs.netやgreen.jbbs.netでないと使えないみたいですよだから本物のjbbsでもhttp://64.71.134.227/というURLじゃ使えないっす。
- 71 ：67 ：2001/11/03(土) 21:52
- >>70
ありがとう。
んじゃ、恒例のDNS変更の時は大変ですね。
34KB
新着レスの表示
スレッドリストへ戻る 全部 前100 次100 最新50
0ch BBS 2004-10-30