【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバの新ロケーション、PIEに関する話題もこちらで。 現在の主要なテーマは、 ・新ロケーション、PIEの安定化 ・pekoサーバ突然死の原因究明 となります。 レンタルサーバー maido3.com 2ちゃんねるの転送量: http://server.maido3.com/pie/ MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html PINKちゃんねるで現在進行中のama作戦については、こちら。 【Project ama】PINKちゃんねる特化型サーバ構築作戦 Part2 http://qb3.2ch.net/test/read.cgi/operate/1082721809/l50 携帯電話特化型サーバ構築作戦については、こちら。 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/ 前スレ 【Project peko】2ch特化型サーバ構築作戦 Part13 http://qb5.2ch.net/test/read.cgi/operate/1085678587/ >>root ★さん そもそもpekoがswapしているってのがそもそも腑に落ちないので大雑把に 計算してみました。投入されているpekoサーバは最低スペックでもメモリを 2G積んでますよね。 で、現在apacheの設定では最大256個の子プロセスが立ち上がります。 簡単のため、cgiの孫プロセスやapache以外のプロセスは数えないでおきます。 この前提では、256個全てのプロセスがそれぞれ8Mずつメモリを使ったところで 物理メモりが不足し始めるわけです。手元のIA32なFreeBSD 5-CURRENT上で のapacheのプロセスは起動時に約4Mくらい消費しています(現実にはapache プロセス間で共有されている部分が多い)。AMD64だからといって、倍にはなって いないと予想できます。 また、LAのデータを見ると256個apacheのプロセスが起動されたことは無いような 雰囲気で、実際にはapacheが100〜150個とかそのあたりでswapが激しくなって 反応できなくなってしまっているように見えます。例のapacheのメモリリークの 影響がどの程度あるのかわかりませんが、apacheのプロセスが大雑把に言って 8Mを越えない内に再起動されるようにMaxRequestsPerChildを再調整してみる と良い気がします。FreeBSDのportsの場合MaxRequestsPerChildのデフォルトは 0になってますが、apacheのドキュメントによると本来のデフォルトは10000のよう です。 乱暴な計算ですが、100000リクエストがそれぞれ32バイトずつメモリリークすると それだけで3Mバイトになります。なので、MaxRequestsPerChildを100000に設定 するのはやや大きすぎる気がしますです。 memoeriesのすべてのバーチャルホストのread.cgiをgame6/news11バージョン (munmap()をするバージョン)に入れ替えた。 なお、oyster901(live8, live9)のread.cgiは既に入れ替え済み。 >>56 詳細なレポートありがとございます。 topとかでプロセスをチェックする必要がありそうですね。 今のcomic4/cはこんなかんじ。(topの出力) PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 8910 www 104 0 54976K 9064K RUN 1 0:02 4.08% 3.37% httpd 8923 www 102 0 54940K 9024K select 1 0:01 2.61% 2.00% httpd 8982 www 105 0 55480K 9540K select 1 0:01 3.12% 1.86% httpd 8989 www 4 0 55272K 9344K accept 1 0:01 2.96% 1.76% httpd 8919 www 102 0 54776K 8864K select 1 0:01 2.11% 1.66% httpd 8920 www 101 0 54816K 8900K select 1 0:01 1.92% 1.51% httpd 8914 www 4 0 55408K 9472K accept 1 0:01 1.83% 1.46% httpd 8928 www 4 0 54772K 8876K accept 1 0:01 2.05% 1.46% httpd 8943 www 104 0 55300K 9392K select 0 0:01 2.25% 1.46% httpd 8980 www 105 0 55016K 9076K select 1 0:01 2.47% 1.46% httpd 8990 www 4 0 55232K 9320K accept 1 0:01 2.22% 1.32% httpd 8949 www 4 0 55024K 9096K accept 1 0:01 2.01% 1.27% httpd 8952 www 20 0 56148K 10236K lockf 0 0:01 1.93% 1.22% httpd 8953 www 104 0 55232K 9328K RUN 1 0:00 1.93% 1.22% httpd >>56 今のgame6。なんとなくふくらんでいってますね。< httpdのRES ちなみにhttpdプロセスは少ない(100もない)です。 もしまた落ちたら、そのときはもっと短くしてみます。 PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 49470 www 96 0 57572K 9144K select 1 0:06 0.10% 0.10% httpd 70837 www 96 0 63772K 15376K select 1 0:26 0.05% 0.05% httpd 38328 www 96 0 58656K 10228K select 1 0:09 0.05% 0.05% httpd 42724 www 4 0 58956K 10536K accept 1 0:08 0.05% 0.05% httpd 55960 www 4 0 56992K 8564K accept 1 0:05 0.05% 0.05% httpd 64126 www 96 0 56452K 8020K select 1 0:03 0.05% 0.05% httpd 558 dnscache 96 0 34112K 32244K select 1 10:08 0.00% 0.00% dnscache 557 dnslog -8 0 2380K 516K piperd 1 6:12 0.00% 0.00% multilog 520 root 98 0 20608K 7412K select 1 1:55 0.00% 0.00% snmpd 24605 www 4 0 66008K 17584K accept 1 0:35 0.00% 0.00% httpd 504 root 8 0 54352K 5828K nanslp 1 0:35 0.00% 0.00% httpd 70769 www 4 0 64748K 16344K accept 1 0:25 0.00% 0.00% httpd 82189 www 4 0 63276K 14864K select 1 0:22 0.00% 0.00% httpd 92470 www 96 0 63384K 14952K select 1 0:21 0.00% 0.00% httpd 91336 www 4 0 63100K 14668K accept 1 0:21 0.00% 0.00% httpd (以下略) 受付嬢au1号(名前なんていいましたっけ)の生誕の儀式をします。 将来的にはau携帯からしかアクセスできなくなる予定です。 以下のDNS登録をお願いします。 +c-au.2ch.net:206.223.150.95 今しがた中の人から、 「事情により儀式は明日になりますー」との連絡を受けました。 ということでもう時間も遅いので、以降の作業は明日以降となります。 明日以降の予定を書いておきます。 2)〜3)は、cの中の人におながいしようかなと。 そういうチューニングをしたつもりなので、とりあえずは今のcと同じ動作でよいです。 4)は、私がごそごそします。それではおやすみなさり。 1)生誕の儀式 2)今cで動いているプログラムをごっそりコピー、動作確認 3)動作試験 4)au以外からのアクセス制限の実施 当分(少なくともサッカーがある間)、live12/tmp3のバックアップタイムを 日本時間朝5時から朝9時に変更することとしました。 ということで、いったんねます。 >>55 え? てことはpeko廃止? Project pekoは頓挫するのか・・・・? >>67 http://qb5.2ch.net/test/read.cgi/operate/1087762418/397 397 名前:留守番 ★[] 投稿日:04/06/22 21:11 ID:??? peko からどんどん banana に移転して +は peko の予感 http://qb5.2ch.net/test/read.cgi/operate/1086435290/154 153 名前: ◆OkmkNwI5zM [sage] 投稿日:04/06/22 16:14 ID:vn8Mjffa >>151 oyster901 live8/live9 cobra2244 game6/news11 cobra2245 live12/tmp3 cobra2246 c/comic4 cobra2247 society2/etc2/food5 ね。 これを再編したいのだと思うけど、 ロードマップというか指針を教えてください。 154 名前:留守番 ★[] 投稿日:04/06/22 16:15 ID:??? >>153 live はそのままで あとは移りたいとこは全部 過去ログを(ry cobraサーバとbananaサーバのI/Oパフォーマンスの違いをみようと思って、 とりあえずiozoneしてみた。 個人的には、普通にbananaとcobraを触っていて一番感じるのがディスクI/Oの速度なので、 誰か比較していただけるとうれしいかも。 banana403(携帯用サーバ) http://mumumu.mu/banana403/iozone.xls 昔oyster243(cobraサーバ)でとったもの http://mumumu.mu/oyster243/iozone.xls >>74 >>78 でfusiaasanになってたw Yahoo!BB 3つとも見れました >>77 ようわからんけど、excelで等高線グラフを作ってみたら bananaのピーク地点がcobraだと台形になった。 >>81 えー 範囲指定してボタン押すだけだから誰でもつくれるお? それにexcelのオマケだからグラフきちゃないしー excel持ってない人も多いし excelファイル開きたくない人も多いし 歓迎する人は結構いると思うよ game6の件。ここにも一応。 867 名前:root ★[sage] 投稿日:04/06/23 23:13 ID:??? 2日動いたというのは正直画期的なので、 read.cgiのmunmap()をやめるのは効果ありか。 次上がったら、comic4/c並みにMaxRequestsPerChildを小さくしてみる予定。 サーバダウン(鯖落ち)情報 Part39 http://qb5.2ch.net/test/read.cgi/operate/1087762418/ 906 名前:root ★[sage] 投稿日:04/06/23 23:30 ID:??? リブートを待っていましたが、速攻ではかからない模様なので、 いったんオフラインになります。 game6が上がって私がオンラインになり次第、設定変更をトライします。 Apacheの数を思い切って減らして、MaxRequestsPerChildを思い切って少なくする予定。 しかし、不安定な状態(read.cgiを動かした状態)でないと試せないところがきついなと。 read.cgiを止めれば安定する(20日以上ダウンなし)ので、 何らかのトリガであることはもう間違いないと。 >>88 まぁ、そんな領域で実験できるのは2ch位なのでむしろ楽しめるかと。 よーわからん2号だけど Writeで SCSI320:ATA100(?)おおむね1.5倍ってかんじ IDEもキャッシュ多めなのか、こんなものかなあ。 readは2倍前後でてるもより。 帰宅。game6はリブート待ち。 で、PCからでもここ↓だけ読めるようにしたので、 ここをチェックいただいている各位におかれましては、ご対応いただけると。 http://c-au.2ch.net/_service/ game6が上がったら、>>86 よりも素直に負けを認めて、 Single CPU設定にしてみるかなぁ。そのほうが簡単だし。 >>93 Single CPU設定にする前に、 いま一度、>>86 でトライして欲しいねぇ・・・ >>94 正直迷っております。上がるまでには心を決めておこう。 >>93 MaxRequestsPerChildを(5000あたりまで)ガッツリ減らす方が効果あり そうな気がする。read.cgi動かしているサーバで希にでも落ちるのは pekoだけじゃないですよね、確か。 今時swap使い尽くすような使い方は滅多にされないから、仮想記憶 使い尽くすあたりにカーネルのバグがあっても不思議じゃないし。 もちろん、SMP特有のバグという可能性もありますが。 サーバダウン(鯖落ち)情報 Part40 http://qb5.2ch.net/test/read.cgi/operate/1088002146/345 345 名前:root ★[] 投稿日:04/06/24 02:19 ID:??? etc2 (cobra2247 = oyster247)のSCSIカードを交換する予定とのこと。 今日になるかどうかはまだ未定。 サーバダウンしたgame6は正規パスでしかリブートをしない方針とのこと。 ただ、シリアルコンソールが復活するかもしれないので、そうすると様子が見られる可能性あり。 【'A`】エトセトラetc鯖なんとかしてえぇぇ【ノД`】 http://qb5.2ch.net/test/read.cgi/operate/1081010089/659 659 名前:root ★[] 投稿日:04/06/24 02:27 ID:??? サーバダウンスレがgame6問題で流れてしまっているので、こちらに。 SCSIカードに問題をかかえているetc2(oyster247 = cobra2247)ですが、 本日午後(現地時間)、SCSIカードの交換作業を行うとのことです。 ということで木曜の午前中にサーバダウンが発生すると思います。 あらかじめご承知おきくださいです。 続報 660 名前:root ★[] 投稿日:04/06/24 02:34 ID:??? >>659 続報が入り、他の作業との兼ね合いで 本日作業が入らないかもしれないとのことでした。 その場合は後日スケジュールということになります。 >>100 どもです。レスしておきました。 なんだか誤解があるようなので。 向こうにも書きましたが、 今回、外にアナウンスする入り口のURLは変更して*いません*。 従来通り、c.2ch.netが入り口となります。 あくまで、内部処理をするホストを変更しただけです。 明日以降DoCoMo専用の受付嬢も作る予定ですが、 それについても同様です。 ということで。 グラフが変というかnews13がこのところずっと不調なわけで LAがそれほど上がっているわけでもないのに激重で ネットワークかハードが怪しいんだが放置されてるわけで >>104 漏れは「転送量限界説」かな?とおもうのですが このグラフが見れないことにはなんともなわけで。。。 ※早朝は軽かったですよ bananaでnewsplusをまかなうのは正直つらいような希ガスです。 game6のApacheの設定を変えた。 メモリを節約する方向。 従来: <IfModule prefork.c> StartServers 64 MinSpareServers 5 MaxSpareServers 32 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 100000 MaxMemFree 2048 </IfModule> 現在: <IfModule prefork.c> StartServers 64 MinSpareServers 5 MaxSpareServers 32 ServerLimit 160 MaxClients 160 MaxRequestsPerChild 100 MaxMemFree 1024 </IfModule> cobra2247 (etc2, food5)のSCSIカードがAdaptecから 他のcobraと同じLSI Logicのカードに交換され、 転送速度が本来の速度になりました。 da0 at mpt1 bus 0 target 0 lun 0 da0: <SEAGATE ST336753LW 0006> Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at mpt1 bus 0 target 1 lun 0 da1: <SEAGATE ST336753LW 0006> Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) ただし、デュアルチャンネルのかたっぽに両方接続されているので、 ぼちぼちケーブルの接続方法を他のcobraと同じに変えてもらうということで。 >>108 DNSサーバのダウン(不調)の原因は何だったのでしょうか? 帰宅。 今日は午後からずっとオフラインでした。どうもいろいろとあったようで。 >>113 DNS鯖の設定(鯖-IP部分だけ)どこかにアップしない? >>114 私は、2ch.netのDNSコンテンツサーバの設定してないです。 (maido3.comの中の人が担当) 私が今のところ触れるのは、 サブドメインの分(uma.2ch.netと・peko.2ch.net)のDNSコンテンツサーバと、 DNSキャッシュサーバ(bananaサーバから/etc/resolv.confで参照されている)だけですね。 2ch.netのDNSサーバはns1.maido3.comとns2.maido3.comなので、 私は触れんです。 @ IN SOA 2ch.net. root.localhost ( ごにょごにょ ) pc5 IN A 38.114.144.85 こんなやつの最新版どこかにないかな? と思ったんだけど ns1.maido3.com内で2chのも設定してるなら無理か キャッシュサーバのアドレスが変わると、Rock54への登録とかも必要かな。 しかし、ねそびれた。 >>119 おつですー Rock54 関連は丁稚どんを含めて大丈夫かと思いますです。banana238 -> 206 系なので BBX の oklist の書き換え(or 追記)が必要なのかな? なんか鯖用マザー新発売ってのを見つけたんで貼っておきますね。 PCIexpress16xスロットにPCIexpress4xな高速ストレージカードを繋ぐことが出来るのなら 結構すごそう。(仕様上は繋ぐことが出来るはず) しかも内臓LANがPCIexpress1x接続。 Tyan、Intel 925/915マザーボードを発表 - RAGE XLを搭載した製品など http://pcweb.mycom.co.jp/news/2004/06/24/014.html http://www.tyan.com/products/html/tomcati925x.html ftp://ftp.tyan.com/datasheets/d_s5130_100.pdf 内臓LANチップの解説 http://www.chipcatalog.com/Broadcom/BCM5721.htm 本日の儀式予定: 1)c-docomo, c-others生誕 2)cアドレス変更 1)は今日のごごいちあたりで。 2)は1)へのリダイレクトがうまく動いたら。 ということで、儀式1)をお願いします。 以下の2つの追加登録になります。 +c-docomo.2ch.net:206.223.150.140 +c-others.2ch.net:206.223.150.145 >>124 ?? おぢさんが「done」書き込みをする前に まさか開いちゃったの? c-docomo.2ch.net c-others.2ch.net みえました。 >>126 振り分けをはじめました。 続きはあっちのスレで。 と思いましたが、儀式第2弾があるのを忘れていました。 以下のアドレス変更をお願いします。 これでDNSが浸透した時点で(変更後しばらくかかる)、 oyster246からの携帯系の分離は完了です。 (旧) +c.2ch.net:38.114.144.180 (新) +c.2ch.net:206.223.150.145 >>130 変更を確認しました。 徐々に浸透していくと思うので、週明けあたりには概ね新cにいくようになるとおもわれ。 >>132 おつですー ところで、 c.2ch.net/_service/ は存在するのでしょうか?@現状、c-others に飛ばされるので確認できませんでした。 # 同じ鯖なのであまり意味はないかもしれませんけれども(苦笑) >>133 旧cにはないです。 新cにはあるはず。でもc-othersのやつをln -sしてあるだけ。 >>134 シンボリックの件、承知しました。 同じファイルなので、巡回外したほうが良さそうですね。 ♪そういえば、 VirtualHost ごとに uptime があるのもちょとばかし無駄なような気もしたりして(苦笑) http://qb5.2ch.net/test/read.cgi/operate/1088080432/856 向こうでレスの山に埋もれるのもアレだとおもうので こっちに転載しておきます、 なんか画期的なことだったらたいへんだし >>138 前にもこの案は挙がっていたような気がしますが。 >>139 はあ。探すのに苦労しました。 これの、 http://qb3.2ch.net/test/read.cgi/operate/1073058944/601- この 661 :root ★ :04/02/17 20:14 ID:??? 書き込みのことでしょうか? これだとすると、全体のトラフィックの制御のように読めますから、 実況の対策として、板ごと、あるいは、スレごとにトラフィック制御 してみる、というのとは、ちょっと文脈が違うかも知れませんね。 たまたま思いついて書いてみたのですけれども、なにぶん、 2chのシステムをあまり理解していないもので、はずしていたら ごめんなさい。 でわ。 mod_netniceの2ch特化版ってのはありかもしれないですね。 >>138 netniceは、いまのとこFreeBSD 4.xだけみたいですね。 将来性はきわめて有望(いろいろつかいでがありそう)なので、 かなりおもしろそう。 2ch的には、FreeBSD5.xが必要になりますか? 分かりました。できるだけ頑張ってみます。 もし差支えがなければ、直接コンタクトを頂ければ、 よりご希望に添った形に持っていけるかも知れません。 おぉ。すばらしいです。 ただ、実際に使うかどうかはわかんないです。 あと、i386じゃなくてamd64にも対応してほしいかも。 私のメールアドレスはこちらのリンクにあるやつになりますです。 http://mumumu.mu/ mod_netniceは面白そうではあるんだけれど、サーバからの出力の 帯域を絞る形で動作しそうなので、結果としてリクエストのはけが悪 くなる予感。リクエストのはけが悪いとapacheの仕組みからいって、 MaxClientsいっぱいまでhttpdが起動し、最悪の場合それが全部 read.cgiあるいはbbs.cgiを実行することになるので、サーバ負荷が 心配だったり。 mod_limitipconn2(/usr/ports/mod_limitipconn2にある)あたりだと、 同IPアドレスからの同時接続数を制限できるので、行儀の悪い クライアントによる負荷を軽減できる可能性があるので検討の価値 があるかもしれません。 でも、当面考えるべきはbbs.cgiの改良だと思う。具体的には、 http://qb5.2ch.net/test/read.cgi/operate/1076666901/743-744 を簡略化した感じで、 1. datファイルヘの書き込みおよびsubject.txtや板topの更新を専門 に行うデーモンプロセスを作る。 2. bbs.cgiは書き込み許可のチェックとか書き込みのサニタイジングなど、 個々のPOSTリクエスト単位で閉じている仕事だけを受け持つように し、実際の書き込みはデーモンに丸投げする。 削除関連などdatファイルやsubject.txtに触る仕事の実体を全てデーモン プロセスにまかせられれば、デーモンプロセス自体の実装には特に工夫 しなくても、効果ありそう。 >>149 書き込み時と読込時では性質がかなり違うのと、現時点での携帯の場合は 平均的に遅いのと不安定という苛酷な条件があるので、Love Affairとは 直接の関係はないかと。>>148 で書いたデーモンプロセスは各種ファイルを 持っているサーバで実行するほうが良さそうだし。 別のところで見た「実況」の問題についての素朴な提案なので、こちらの 議論の流れとはずれているのかも知れません。その際にはご容赦を。 帯域の話は、フェアキューイングを使うと、帯域は絞りませんよ。たとえば、 リンクが100Mbpsあるとすると、「実況スレ」だけしかリクエストが無いとき には、100Mbps使いきりますし、そこに同じだけの他のリクエストが来たとき には、50Mbpsづつフェアシェアすることになります。その際、システム全体の スループットは、理屈のうえでは変わりません。 ただ、それは、システムのボトルネックがネットワークI/O側にあるときの理想 的な状況で、かつ、クラス分けのアルゴリズムがうまく実装できたときの話です ね。CPUがボトルネックであれば、いくらネットワークでフェアキューイングし たとしても、あまり意味は無いでしょう。その際には、プロセススケジュー リングの方を、スレ毎にフェアシェアしてやる必要が出てくるのでしょうね。 直感的には、ディスクアクセスが噛むと話が変わってきますけれども、アクセス の多いスレはバッファキャッシュがホットでしょうから、最近のプロセッサで あれば、結構、burstyに出力されているような気はします。チューニングされた コードであれば、なおさらです。そうなると、ネットワークI/Oでのフェアキュー イングが、「実況」問題に効果を発揮する可能性はあります。ただ、実際の ところは、やってみないと分からないというのが正直なところですね。 リクエストが溜まってクライアント数が増えてしまうという問題については、 mod_netnice固有の問題ではなくって、システムの処理能力を上回るリクエストが 生じているときにはいずれにせよ生じる問題だと思います。その際には、選択的 に「実況スレ」のリクエストを処理しているプロセスをアボートさせるしかあり ませんね。もっとも、その処理自体は簡単なはずですよ。案外、そうしたコード を埋めるだけで、問題の殆どは解決してしまうのかも知れませんね。 思いつきで書いているので、間違っていたらごめんなさい。 >>151 フェアキューイングの話はそのとおりだと思います。理解しているつもりです。 で、現状の2ちゃんねるの負荷問題というのは、外野から見ている限りでも いくつかのパターンがあって、書き連ねると次のようなものになります。 1. サーバの契約上の帯域制限に掛かってしまう。 2. ネットワーク的に遅いクライアントが沢山繋がった時に、apacheの性質上 設定したクライアント数分httpdが立ち上がり、その結果物理メモりが破滅 的に不足し、その結果スラッシングが起こり、見かけのCPU負荷が上がる。 3. bbs.cgiの場合(書き込み時)、ファイルの読み書きを行うプロセスが多数起 動される。特に実況時は同じファイルを読み書きするプロセスが上がる。 cgiなのでcgiを呼び出したapacheの子サーバはbbs.cgiが終了するまで リクエストの処理を終えられないため、2の場合と同様の問題が起こる。 1の問題は契約の話なので、技術的には如何ともしがたいわけですが、 この制限でクライアントへの応答が悪くなった時には、LAが上がったりは しないはずなので、現実には2の問題が最も大きいと考えられます。 実況サーバの場合は3に由来して2と同様の問題が起こっていると考えられ ます。 なので、まずは2、3の問題を解決しないと、フェアキューイングをしても、 スラッシングの影響が大き過ぎて効果が出ないのではないかと思います。 2の問題はサーバの能力を越えた設定をしないようにapacheの設定を チューニングすることで解決できます。で、>>148 のは、3の問題を解決 するためのアイデアです。フェアキューイングの効果を求めるためには、 2、3のような状況が起こらないようにしておく必要がありますよね。 >>151 >>153 ども。1レスをもちょっと短めにするといいかもです。 (ここは60秒規制なのでややつらいですが) 中身のコメントは別途。 で、おれさまメモ。Zend Optimizerの効果はかなりある。 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/797- >>154 bbs.cgi関連を最適化しても恩恵を受けるのは実況サーバだけという 気もするので微妙ですが、もし手を付けるのであれば教えてください。 デーモン部分のコードをCで書きますです。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる