問題点と解決方法
2ch専用ブラウザ対応について
互換性はmod_rewriteでURL動的書き換えでいんじゃない?
方針としては、
1.DAT落ちした物を定期的に(Cronで)、別フォルダに移動する
2.別フォルダは ochitayo/XXX/YYY/file.dat
のように2段階〜3段階ぐらいのハッシュで求まる多段ディレクトリにする
1フォルダ1000個でも3段あれば1,000,000,000個は持つわけだし足りなきゃ4段・・・
3.読み込むときは、メインディレクトリにファイルがあればなにもしない。
ファイルがなければ、バックアップをさがす
4.ブラウザからの読み込みはmod_rewriteで3をやらせてどちらかのファイルを読み込ませる
で良いかと。
このロジックなら基本的に現行スクリプトがほぼ使えるので、ソースなくても出来るはず・・・
686 名前:以下、名無しにかわりましてモナーを取り返します[sage] 投稿日:2005/09/23(金) 20:25:38 ID:8CsH08260
mod_rewrite
ブラウザから要求されたURLを書き換えてapacheのエンジンに伝える。
apacheはあたかも変換後のリクエストが来たかのように見える。
互換性は保たれるはず。
read.cgiもmod_rewriteでぶっ飛ばすとしてbbs.cgiの処理だが
$t = time();
$_3 = substr($t, -3, 1);
$_4 = substr($t, -2, 2);
こんな感じかな
IOを自前じゃなくMySQLに任せるっていうのはどうなの?
Perl PHP C出来るやつちょっと来いって書いてあったんでとりあえず来ましたざっとしか見てないが、いっそログをDB化しちゃうってのはどうなの?
datシステムのディレクトリ構成を改変
>>141あたりのアイディアを採用。現状でもある程度行われている?>141 名前:以下、名無しにかわりましてモナーを取り返します[sage] 投稿日:2005/09/25(日) 11:35:18 ID:EHs6b5yb0
>datのスレ番号をキーにしてディレクトリを細分化する案の掘り下げ。
>
>〆拱化したディレクトリ単位に、datのタイムスタンプをチェックして
> 新しくdatが追加された時だけindex.html, subject.txtを作る。
>
>∈拱化したディレクトリ単位のindex.html, subject.txtを 連 結 し て
> 板全体のindex.html, subject.txtを作る。
>
>現行システムでは毎回index.html, subject.txtを作り直すせいで
>処理が重すぎて問題になっているなら、,能萢対象を減らせるし、
>それほど重くはない△埜醜團轡好謄爐箸慮澳浩もとりやすくなる。
>
>こうするとだな、,魴擇するのが主眼になるが、ディレクトリ細分化はいままで話されていたような
>datのスレ番号の「下n桁」をキーにするのではなく、(例:1127558513.dat→85/13/1127558513.dat)
>datのスレ番号の「上n桁」をキーにするのが正解だよな?(例:1127558513.dat→1127558/1127558513.dat)
過去ログを一定数でtar圧縮
>>60、>>68参考。圧縮処理で余計重くなる?>60 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/24(土) 23:56:50 ID:7IIQB9tb0
>過去ログを一定数tarで固めるのはだめかな?
>68 名前:以下、名無しにかわりましてモナーを取り返します[ほしゅ] 投稿日:2005/09/25(日) 01:01:07 ID:k6zveWjo0
>>>60
>過去ログを、随時読み出せないといけないそうなんです
>でも、.tar から読み出すのはそんなに難しくないですから、いいかもですねw
subject.txtを常駐プロセスのindex compilerが生成
>>144、>>147参考。効果は未知数>144 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/25(日) 11:46:10 ID:k6zveWjo0
>板圧縮プロセスが、待避した.dat のリスト(形式は中間状態)を吐く 排他制御は適宜
>index compiler はプロセス常駐していて、30秒おきにsleep から目覚め、
>中間ファイルを引き受け、index を生成する
>ただし、何かの要請があって、sync の必要があったら、シグナルを受けて実施する
>単にquery したいだけなら、index compiler に問い合わせることもできるようにする
>
>なんて言えばいいかな…
>147 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/25(日) 11:47:59 ID:k6zveWjo0
>index compiler がexit せずに常にメモリに居れば、増分を受け取ってindex を生成するのは、
>そんなにコストがかかんなくていいじゃないか、…という。…甘いかなぁ…
>211 名前:以下、名無しにかわりましてモナーを取り返します[sage] 投稿日:2005/09/25(日) 21:22:30 ID:2DVVKN8I0
>>195
>
>>subject.txtを常駐プロセスのindex compilerが生成
>そんな問題もあったんだ・・・
>
>これこそmysqlで管理して、インデックス作らせれば良いんじゃないの?
>数万件のデータとかそれこそSQLが得意でしょ。
>
>自前で管理してたらそらメモリオーバーフローとか出そうだもんねぇ。
>
>212 名前:193[] 投稿日:2005/09/25(日) 21:43:00 ID:1CSH1zFR0
>>>211
>それは問題と言うか、subject.txtの生成処理を減らす手法では
>
>mysqlかpostgresかわからんけど、「SQLが駄目な理由」なり
>「subject.txt生成処理を自前で作らなきゃならない理由」なりが無いなら
>SQLでもいいのでは?
>
>でも今ID:k6zveWjo0氏が一生懸命このあたりを作ってるのでそれを待ちましょう
>
>213 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/25(日) 21:43:48 ID:k6zveWjo0
>ここでいう、index とは、subject.txt やindex.html (特に前者)といった、
>plain text のindex です こいつを参照している、後継のモジュールがあるらしくて
>
>VIP のためだけにmysql を入れてくれるかどうかはあやしげなので、まずはナシでデモしてみるです
>軌道に乗れば、DB をかましたほうが効率はよさそうですね
>
>メモリのポカを防ぐべく、まずはあえてPerl で書いてみるですよ
>
>214 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/25(日) 21:44:30 ID:k6zveWjo0
>いたた被った
>
>215 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/25(日) 22:13:44 ID:RYjyM8/W0
>>>213
>今より高性能なものが出来上がれば互換性はなくてもいいって言ってた気がするし
>DBぐらい入れてくれるんじゃないかなぁ…
216 名前:以下、名無しにかわりましてモナーを取り返します[] 投稿日:2005/09/25(日) 22:31:47 ID:k6zveWjo0
入れてもらえるかもですが、必要性を提示しないといけないかもです…
とりあえず、今書いてみてるのは、板圧縮モジュールから、dat 落ちログを受け取ると仮定して、
定期的に読み出して、index (subject.txt) を書き込み、そのままindex をhash に保持するスクリプト
そいつで、どんくらいキツいかみてみるですよ…
2005年09月25日(日) 22:35:09 Modified by chin2shu3