bbs.cgi再開発プロジェクト 3
■ このスレッドは過去ログ倉庫に格納されています
ていうかbbs.cgiとread.cgiのソースはどこよ? bbs.cgiはひどいスパゲティソースで、見た人が次々に消えてしまう
らしいから、一から作ったほうが早いかもよ。
ということで、がんばれ。>>736 >>736
いわゆるNASなどを使ったソリューションではよくある形ですね。
10.0.0.0/8とかつけとけばいいと。
でも、NFSとflockって大抵の場合、きわめて仲が悪かったり。
(私は何度も痛い目にあいました)
いずれにせよ、細かなI/Oが多数発生するような系では、
flockはともかくNFSを使う気は全くないですね。
NFSだと、Apache的にEnableMMAPやEnableSendfileとかがうまくないので、
パフォーマンス的に激しくつらいです。
例えばhome directoryの共有みたいな用途には便利だし、
うまくやれば管理も楽なので、NFSという技術そのものを否定するものではありませんです。
単純にライブな掲示板システムには、ちょっとなぁというだけで。
で、flockは >>735 みたいなやり方の負荷は、確かに高くなりません。
でも、他の人を「待たせる」ことが、そもそも負荷というか、重荷というか、コスト高になります。
掲示板システムって、もう、待たせちゃいけない。システムも、ユーザも。
待たせるぐらいなら、他の手段(rename()をうまく使うとか)を使うですね。
某氏じゃないけどNFSはこういう用途に使う場合には、
Network Failure Systemだぐらいに思っていたりして。 >>740
またせちゃいけないからflockはつらいってか。
じゃあ手段1。書き込む先のファイルを分けることだな。
$thread_num = スレ番号;
$pid = $$;
open(WRITE,">$base_directory/$thread_num/$pid");
でもって、これらをマージするのは別のデーモンが行う。
もしくは手段2。デーモンがunixソケットの口を開けて待っていて
bbs.cgiはそのデーモンに向かって次々と書き込みリクエストを投げつける。
実際のファイルへの書き込みはデーモン1プロセスが行うので
排他処理は不要。
ていうか俺が作れってか >>741
> ていうか俺が作れってか
期待してますです。
私は「作られたものの性能をできるだけ発揮させる」とか
「既にある仕組みを用途に合わせて適用する」とかいうのは
なんとかやれますけど、スクラッチから作るのは正直苦手なんで。 NFSとflockの両方を提案したがこれは両方の組み合わせを提案したわけじゃないのであしからず。
NFSは「読込負荷の分散のためラウンドロビン化された表向きCGIサーバー群」が
データを抱える裏方のサーバーに読みに行く場合のみ。
flockは書き込みに関してだけで、これは単一のホストがローカルドライブに対して行う。
俺が考えている構成は以下のような感じ。
まず表向きのCGIサーバー群を用意してラウンドロビン化。
裏方サーバーはデータの管理専用で板ごとに分散。
表と裏の通信はTCP上の独自プロトコル。
表サーバーについて: read.cgiは直接裏のサーバーに問い合わせるのではなく
表サーバー内で動作するキャッシュ機能提供のデーモンを経由する。
キャッシュ能力を持つデーモンは逆proxyの効果を上げる。
裏サーバーについて: 読込と書込の2つのデーモンを走らせてTCP listen。
書込デーモンはTCP口のところである程度バッファ能力を持たせておけば
過去flockを使ったとき発生した「待ちのための負荷増加」を減らせるはず。
読込デーモンの処理を極限まで減らすため、
HTML化やl50分の切り出し等、読込時によくある動作は書込デーモンが
あらかじめ行ってファイルへ書き出す。
本当は読込デーモンと書込デーモンを一体化させて
できるだけファイルを経由しないオンメモリ動作にした方がさらに効率的なのだが
開発に時間がかかるしバグ取りが大変だしメンテできる人が減ってしまうことになる。 743続き
書込時の流れ:
[表鯖]bbs.cgi
↓
[表鯖]書込デーモン
(チェックやフィルタなどはこことbbs.cgiだけで行い裏の負荷を下げる)
↓
[裏鯖]書込デーモン
読込時の流れ:
[表鯖]read.cgi
↓
[表鯖]読込デーモン
(キャッシュ能力を持たせて逆proxy状態に)
↓
[裏鯖]読込デーモン
表鯖はデータを抱えない同一構成のマシンを大量に並べてラウンドロビン化。
そうすりゃ表鯖にいくら負荷をかけても数の力でごまかせる。
ていうかこれだとNFSは不要か。 そうそう、書きこむ人 (bbs.cgi) がｲﾊﾟｰｲいるから 3000 超えちゃったり。
dat 直読みも表面的には「直読み」だけど本当は DB アクセスにしちゃうとかね。
AddTypeapplication/x-httpd-cgi.dat
AddHandlercgi-script .dat
とかとか。 そして次の世代の２ちゃんねるが生まれて来るんですね、
みんながんがれ 途中で書き込みしてしまいました。１時間ほど前からhuman3㌧でます、対策よろしく 見習い▲ ＝ 仕事人 ＝ 夜勤 ＝ Z社員 でしたっけ？
ﾗｳﾝｼﾞとかの人の多いところには排他入れたいけど、
入れると負荷が高まるというトレードオフをどう克服するか
楽しみに待っていますよ 書き込みデーモンの話題とか見ると、去年の暮れから話がループしているな。
実際のコードを書くためには、bbs.cgiをサブルーチン単位で公開できるところだけでも提示してくれないと書けないと思う。
どうなんですか? root★氏やひろゆき氏的にそのあたりの書き込みサブルーチン公開は? >>751
んー、だから鶏と卵問題で前進していないから、いいかげん最初の一歩を踏み出しましょうということで。
wikiに公開できる部分を張ってもらうのがいいと思う。
まあ予想されるひろゆき氏の答えは「どの部分を非公開にしなくちゃいけないかも分からない」だったりして。 >>753
その程度もわからないのだったら、いっその事c化しても問題なさそうだな(w >>755
みたいですよ。
もっとも、公式見解が聞きたいところだけどw >>757
一応連携しているはず、と信じたい。
見習い師いわく、「bbs.cgiは完全な挙動をしている」。
しかしながら、
・perlccの吐くCソースとバイナリが大きいのでシェイプアップの余地がある。
・スパゲティソースであることが過去の議論から明白なので、
処理過程も見直せば大幅な負荷軽減が期待できる。
・ディスクI/Oまわりの見直しでディスク負荷が軽減可能。
今のソースはコストのかかるfopen()コールが不必要に多い模様。
などの理由から、私はCでやれるんならそうしたほうがいいんじゃない？という意見。 結局1から作り直すことも出来ず
ソースを全部公開することも出来ず
一部分を公開して→直すの繰り返しで
スパゲティ状態を直すことも出来ず
これじゃとても再開発とは呼べない気がします
と禿外な事言ってみる 運営が欲しいのは
沢山のプログラマーではなく一人の天才プログラマー とりあえず
use warnings;
use strict;
つけて動くようになったら
mod_perl化… じゃあ、オブジェクト指向で書き直してみるとかｗ
以後、部分公開も楽になるかな サザン★さん お呼び出しです
F22 で proxy999 を取っていると思いますが
全く同じルートで proxy998 も取ってください。
各サーバが BBQ の proxy998 も取りに行きます。 >>765
かんりょうでーす
999 と同じ場所に 998 がおいてありますー >>766
どもども
中身はなにもしなくていいですー
たぶんなにもしていないとおもうけど 某ぶぇらさんみたいな喋り口の人が来て、改造案で気を吐いていますね
ここじゃ押してばっかりだと、ｵｼﾓﾄﾞｻﾚﾏｽﾖｰヾ('-')ﾉ for some reason
bbs.cgi を更新したので peko サーバよろしくー > root★さん >>771
live8/9/10/news11 done. >>768
あうーん
やっぱりあちこち欠けて(編集されて)配られるので
F22(各サーバ)が直接 qb4 の 998 を見るようにしました。
ということで、 bbq 側(f22本体)からは 998 はずしてくださいー >>772
どもです
これで ほとんど bbs.cgi を更新しなくても済むようになりました。
＞729
そんなしょぼいコードを参考にしたら２ちゃんねるは壊滅しますよ、と。 GoogleもUTF-8が標準になったことだし２ちゃんねるも
ログとかhtmlとかUTF-8にしてみましょうＹＯ！
別にメリット無いっすね…(´･ω･`) 別に無い事もないけどUTF8への変換ってコストかかるしやめといた方が良いんでは。
あとサイズもでかくなるような。
2chブラが全部作り直しですよ
もしShift_JISのログとUTF-8のログが混じるとその判別も必要になるし メリットが無いどころかデメリットが特盛りなのだった そいやスクリプト側でわざと負荷かけてディスクI/Oの負荷を減らそうって話が
途中出てなかったっけか。
Unicodeは好きになれない。
でも、そこに未来があるのは否めない。 こちらへも。
【Project peko】2ch特化型サーバ構築作戦 Part11
http://qb3.2ch.net/test/read.cgi/operate/1082990543/800-807
800 ：root ★：04/05/08 02:29 ID:???
で、ここの過去スレでも書きましたが、どうもbbs.cgiはたまに暴走することがあるので
(FreeBSDだけじゃなくてLinuxなマシンでも見たことあり、理由は不明)、
何か対策をする必要がある予感がします。
なおuma/pekoサーバでも以前からこの症状起こっているので、
(以下略)
サザン★さんに質問でーす
qb2 にある板は他の板との共存は可能ですか?
つまり何を目論んでいるかというと
BBQ , qb2 ,qb3 qb4 等を一台のサーバでまかなおうと、
BBQ , qb5(qb2+qb3) qb6(qb4) ってな感じで、 初めて書き込みするのでこっそり怖がりながら書き込みます。
# 某所で鯖管理をやっていた関係でつい提案したくなってしまって。
2chのサーバはなんとなくホストによって板が分割されていますが
実際には一つのホスト名で、全すれが運用できるように思えます。
たとえば、
+--------------+ +---------+
| | | |
| 負荷分散装置 |------| L3switch |------- ....多数のread.cgiサーバ（Apache）
| (LVS) . | | |
+--------------+ +---------+
|
|
+------------------+
| Cluster NFSサーバ |
| OpenAFS・Coda |
| もしくはRawDB関係 |（もちろんこれも多数）
+-----------------+
・LVS-DR(Linux Virtual Server Direct Routing)構成でL3switchにデータ負荷分散を
行い
・dat関係は、ClusterNFSもしくはOpenAFS、Codaを利用して分散ファイルシステム化
もしくは、データベースを利用してHDDアクセスの効率化。
・データベースもPostgreSQL系であれば（最近MySQLもそうかな）、負荷分散構成をくめたと
思います。
・すべての書き込みは負荷分散装置を利用すること。
このようになると、ハードディスクのアクセス速度が落ちると思われるようですが、
実際にはIDEのサーバであれば一般的なL3スイッチの処理速度以上に処理を行うなんてこととは
難しいようですし（というよりプログラムの効率あげないと無理）。
などというのはどうでしょうか？ 詳しく構成をくむ必要があればもう少し考えますが・・・。 >>786
このへんは、何度となく提案されてますね。
たぶん、「お、こりゃいいかも」と思えるような*具体的な*システム構成
(>>787のような概念図レベルではなくて)を提案できるとよいのかも。
特に管理人が納得できるようなのだと、より望ましい気がするです。 >>788
あ、レス番号間違えた。両方とも>>787で。 板移転がうざいと言う人が少なからずいるわけで（これが原因でメインをギコナビへ移行中）
p://鯖名.2ch.net/板名/～ではなく
p://板名.2ch.net/板名/～にした方がいい感じ
板移転した場合はＤＮＳ側でＩＰ(鯖)変更する >>791
D:\katjusha_2ch\log\pc2.2ch.net\mysv\
D:\katjusha_2ch\log\pc5.2ch.net\mysv\
D:\gikoNavi\Log\2ch\mysv\
D:\jane\log\ネット関連\mysv\
*janeは多言語環境の場合（削除不可能な）文字化けフォルダを作る為論外
何か？ >>794
なじぇ～？
と聞くのはやめよう
なんとなく分かった
それなら
www.2ch.net の鯖を大量に作る
*download.windowsupdate.com をnslookupして下さい
これが外部と接続できる鯖
リダイレクトで内部鯖の内容を返す
www.2ch.net/sec2ch/ => qb3.2ch.net/sec2ch/の内容を出す
www.2ch.net/mysv/ => pc5.2ch.net/mysv/の内容を出す
この時qb3.2ch.net・pc5.2ch.netは外部から直接の接続不可 ( ﾟДﾟ)ﾎﾟｶｰﾝ
鯖分割するいみないじゃん。 >>799
>板移転がうざいと言う人が少なからずいるわけで（これが原因でメインをギコナビへ移行中）
これでしょ。負荷分散の考えとは別かと 確かにユーザとしては板移転への対応はわずらわしい。
板移転はユーザの手間を考えると、管理側としてもおいそれとは
できないんじゃないかな。
DNS 使えば解決できるよね。 かちゅーしゃのために2chが存在するのかよ、という話ですな、、
>>790 >>792 これじゃあ反感もたれてもしゃあない。>>787とは別の話ですよ、 >>787
これをやろうとすると2chの現状のアーキを相当いじくらないといけない予感。 bbs.cgiの話じゃないな。
批判要望板にでもスレ立ててね。
意見ありがとうございます。
そですね、もう少し具体的な案にしてから持ち寄りたいかなと思います。
私が一番メリットとしたいのは、負荷分散装置を介することによって、
プログラム的には一つのホストに対しての書き込みを行うのみ（クッキーとかありゃあしますが・・・）
を行うように見せるだけでよく、言ってみればread.cgiやbbs.cgiを
すべてシングルソース化が行うことができるように思えます。
つまり、多数のサーバ環境を考えるのではなくて、
一つのソースコード（実行ファイル）が複数のホストにコピーされているだけで
2chの運営が行えればいいかなと。
そうなれば、削除人分担とかサーバ管理分担とかすごく楽になると思います。
機能的には、HTTPサーバとファイルサーバ（DB?）の二つになるだけですから。
あと、負荷分散機にかかる負荷はほとんど無いと思ってください。
実際テストしている環境の中では、6000セッションを行った場合でも
負荷率は0.00でした。平均アクティブセッションはだいたい300を越えることもあまり無かったですが。
えーとというわけなんですが、スレをたてるほど意見も固まっていないので
いちど意見が固まってからもう一度投稿します。
そのときにスレたての話と言うことで・・・・。 あと、どうせアーキテクチャとインフラ周りをいじるなら
可能な限り現状を無視しつつ、可能な限り互換性（データぐらい？）を
取ろうぜというのが方針だったりもします。
どうせなら早く・管理楽のほうがあとあといいもーんといい感じです。
ではでは。 787氏
とりあえず2chのデータまわりで一番重要なのがdatの互換性ですからね。
そのあたりさえどうにかなれば後はいかにして負荷を減らすかという問題になりますから。
直接メールであなたの提案を総帥に伝えたほうがいいかも。 どうもです。
>> ▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo さん
いやぁ、そこまで行くようなものでは・・・。
本気でやるなら死ぬほど本気でやりますが、
まだそこまでのこととは思っていませんので。
今のところせいぜい土日の暇つぶし程度のものです。
それに現状がよくわかっていない中で特攻かけてもこわいし。
あと、アーキテクチャとネットワーク周りについてですが
たぶんデータ周りについての互換性保証はまぁー時と場合によるかと。
面倒ならば、分散ファイルシステムで共有フォルダでも作った方が早いし、
データベースの限界を試すのなら、データベースを作った方がいいし。
その辺はもう少し2chのサーバ現状知ってからかなぁと。
ではでは。 SFでも取り組みがあるみたいです。
apache_modと通常バイナリとどっちが早いんだろ。
http://sourceforge.jp/projects/mod-bbs/ he.netのスイッチの帯域問題について検索したか?
L3バランサーの超具体的な設定法(confファイルをそのままソースで貼るぐらいのレベル)
このあたりを解決して提案するのはいかがだろうか?
だんだん関係ない方向に言っているような悪寒
>>810
見習い師いわく、「８月までにheからは撤退」だそうで。 >>786
削除系の板（saku、saku2ch）とそれ以外の普通の板を同じサーバ置くってことですかー？ >>812
qb5 = qb2 + qb3 をやろうかなって思っているけど
ちゃんと動くかな? が知りたいのです qb2 削除要請/削除整理/削除議論
qb3 運用情報/規制情報/規制議論
がqb5配下に集約するわけですね。 >>814
qb2 の bbs.cgi は他のサーバと統一しているので、いけるはずですー
そのサーバには sakubbs.cgi 入れないといけないですけど、 >>809
誰がやってるのかと思ったら本7でﾜﾛﾀ >>740
利用者を(見かけ上)待たせない小技。
処理の最初で標準出力と標準エラー出力を閉じると
利用者のブラウザには結果がすぐに表示される。(htttpd依存？)
成否が分からないのが難点ですが．．．
-----------------
#!/usr/bin/perl
print "Content-Type: text/html; charset=shift_jis\n\n";
print "処理を受け付けました";
close STDOUT;
close STDERR;
# 時間の掛かる処理
>>816-817
doronpo.cgiも入れてくださいね。。。。 >>819
書き込み後にウエイトを置いてるように、
利用者をわざと待たせるようにしていたり、、、
＞最近のbbs.cgi >>821
途中経過を表示させるってのはいかが？
アクセス規制チェック中。。。 OK
連投規制チェック。。。 OK
ごにょごにょチェック中。。。 NG
ＥＲＲＯＲ！
お布団干したままですよ（￣ー￣）ﾆﾔﾘｯ
みたいな。 途中経過を表示することになんか意味あるのかなぁ、、、 >>822
エラーメッセージ全部で何種類あるんだ… >>823
リロード抑止にならないかなって。
何も表示されることなくただ待たされるとなると F5 押したくなるっていうのが一般的心理かと。 あと蛇足になるんだけれども、書き込み後の自動ジャンプは切れないかな？
わざわざ100KB以上もある板トップに強制移動したところで無駄な転送が発生するし、
誰もが板トップに戻ることを期待していない（書き込み元のスレッドに戻りたい場合もある）かもしれないし。
板トップの広告に関しては、「書きこみました」画面に入れてもいいんじゃないかな？ それだったら
「書き込み処理しています、しばしお待ちください。。。」
(エラーならここで表示)
(処理が終わった)
「終わりました。５秒後にトップページへ飛びます」
(直後にmetaタグを仕込む)
(終わり)
でいいような気がしますが。＞提案者＆総帥 「歯みがいたか?」
↓
「宿題やったか?」
↓
「風呂はいったか?」
↓
「妹の様子はどうだい?」
↓
「肛門の調子はどうよ?」
でいいような気がしますが。 >>825
少しくらい表示してもｲｲが、ひろゆきの嫌いな広告スクリプトにも情報を提供することになるわけで。
自動じゃんぷきれー、
っつのは前からさんざんがいしゅつきしゅつだった希ガス元素。 本題とは逸れるが自動ジャンプなんて要らないと思う。
-------------------------
書き込みが終了しました。
・○○板(リンク)
・にちゃんねる(リンク)
-------------------------
これくらいで良いっしょ。
>>825
2ちゃんブラウザーには効かないぜ
書き込みウィンドウが固まって本体まで固まる奴があるからイライラするだけさ >805
そこそこ使えるL4 ロードバランサって300万円ぐらいするよね、Alteonとか
F5とかServer Ironとか。
それを海の向こうに設置して運営するコストは馬鹿にならんと思う。
このての保守契約は24h365dayにすると極端に高くなるから 負荷分散機のパフォーマンス調査を行っていました。
むちゃくちゃ返信遅れていますし、ややスレ違いな場所に返信してごめんなさい。
・・・そろそろスレたてた方がいいのかな・・。
>835
そうなんですよね。高すぎるんですよ。
ただいま、負荷分散機のパフォーマンス調査を行っているんですが、
やたらと古いデータしかないんですよね・・・。
ttp://www.veritest.com/clients/reports/f5/layer4_layer7_comparison.pdf
ttp://www.linuxvirtualserver.org/Joseph.Mack/performance/single_realserver_performance.html
やっぱりソフトウェアベースでは無理かなぁ。
となると一度実験してみないとだめかも、どこかでこっそりとやってこよう。
■ このスレッドは過去ログ倉庫に格納されています
