【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2

**FOX ★** · 04/07/01 13:55

日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。

たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、

Love Affair 作戦。
Part2 大黒埠頭

前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/

**げろっぴ** ◆/lQMO72QVo · 04/07/01 13:56

ヽ(･∀･)ﾉｳﾝｺｰ!!

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 13:58

２なら２ちゃん閉鎖

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 17:09

●はＰＣと共通で構わないのでは？
携帯上で購入可にするのは難しいのでしょうかねやはり

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 17:46

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 20:18

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 21:30

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 21:36

**動け動けウゴウゴ２ちゃんねる** · 04/07/01 21:38

http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/597
597 ：だいこん ★ ：04/07/01 15:36 ID:???
毎日五個くらい携帯規制リストに追加している気がする。。。
リストが大きくなると、bbs.cgi が遅くなるというか負荷が上がるというか
処理が重くなるというか、、、

**root ★** · 04/07/01 23:55

>>9
携帯用判定文字列ってどんなかんじなんでしたっけ。
DNSにうまく載せられるのかしら。

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 02:24

私はパソコンがないので携帯から２ちゃんを閲覧しています。
携帯から閲覧できる機能は、とてもありがたいのですが、
そのせいで２ちゃんねるに負担をかけたり、以前のような閉鎖危機に陥ったりするのは嫌です。
サーバーの負担になるのであれば、携帯からの閲覧機能は無くてもいいです。
悲しいけど、２ちゃんねるが無くなるのはもっと悲しい。

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 04:04

>>11
俺はPCオンリーのユーザーだが君みたいな人にはなんとかしてあげたい

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 05:27

寄付とか受け付けてみたらどうでしょ？

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 09:31

>>10
http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/ 辺りを見ると、

au　　　　¥d{14}_[a-z]{2}.ezweb.ne.jp
docomo [A-Z]{5}¥d{6}　又は　¥d{15}

のようですねー。

vodaはよく分からなかったんですが、
http://specters.net/cgipon/labo/c_env.cgi?c=j&e=HTTP_USER_AGENT とか見ると

voda　　 {A-Z]+¥d+

でいいのかな。

auの "_" 以外は大丈夫そうですねー

◆BFzK/mtqM2 · 04/07/02 10:08

規制するのは端末固有情報だから、bbs.cgi叩きにいくときしか出さないはず。

**root ★** · 04/07/02 10:33

そうだ。せっかく占有のスイッチでつながってるんだから、
datディレクトリをNFSするというのはどうだろ。

あとで、やってみよう。

**未承諾広告※** ◆TWARamEjuA · 04/07/02 11:01

use Digest::md5;
:
:

sub Get_Mobile_ID($) {
my $Mobile_ID = Digest::md5->new;
$Mobile_ID->add(shift);
return $Mobile_ID->base64digest;
}
:
:

DispError('ＥＲＲＯＲ！', '寄生虫')
　if join( '.', unpack 'C4', sprintf qq|%s.bbm.2ch.net|, Get_Mobile_ID($ENV{HTTP_USER_AGENT})) =~ /^127.0.0/ ;

UA をそのまま MD5 にして bbm（仮名）送りはちょと強引かな？(^-^;)

◆BFzK/mtqM2 · 04/07/02 12:11

確かにNFSにするのが一番簡単ですね。
それならばクラシック側は変更もいらないですね。

**root ★** · 04/07/02 12:17

>>16
datの下だけNFSにすると「キャッシュが作成できません」と言われるなぁ。
たぶん、何か呪文が必要なのかも。
これ以上は中の人に聞かないと。

**root ★** · 04/07/02 12:17

>>18
単に、datの下をNFSに(動かしながら)するんじゃだめなんでしたっけ。
何か設定が必要なんだっけか。

**root ★** · 04/07/02 12:19

うーむ、NFSじゃなければいきなりmvしてもいけるみたい。
だとすると私の設定の問題か。

**root ★** · 04/07/02 12:24

>>21 は勘違いでした。どうもいきなりmvするんじゃだめかも。
結局 >>19 か。

◆BFzK/mtqM2 · 04/07/02 12:29

パーミッションはどうなっていますか？
777ならキャッシュ作れると思うんだけどな～

**FOX ★** · 04/07/02 12:31

出来れば「目的」を書いてから「手段」(たとえば >>21)を書いていただけると
とてもありがたいです、

なにをしたいんだろう
そしてそれは何が目的なんだろう
結果どうなったんだろう

**FOX ★** · 04/07/02 12:49

マーリンルージュ作戦の目的をおさらいしよう。

携帯からのアクセスは速度が非常に遅い等の特徴があり
２ちゃんねるのサーバ全体のお荷物となっている。

受付嬢を置く等でそれが原因となる負荷
速度が遅いのを２ちゃんねるの各サーバへ
直接影響を及ぼさないようにダム(バッファー)になって
動作する、またディレイ値を設けることで全体の負荷もさげようです。

つまり

1) ダム(バッファー)になり通信速度の遅さを吸収し、全サーバを助ける。
2) ディレイ値を設けて、全体のアクセスを減らし、全サーバを助ける。
3) フロントのマシンは DSIK IO をしないで、通信に専念
4) BlackGoat はdatのキャッシング(遅延値=可変)に専念
5) どんなにアクセスが来ても二ヶ月はリブートなしで動くように、

大黒埠頭は
BBM等の各種一元管理＋四台目以降の増設方法(テクニカル、ポリティカル、エコノミカル)です

**root ★** · 04/07/02 13:00

>>24
今回の目的は、前スレにもありますが、

・PHPによる各種処理
・datキャッシュへのディスクI/O

を、分割するためのものです。

今回のNFS化がうまく動けば、現在のクラシックメニューのプログラムを変更せずに、
ディスクI/Oだけをバックエンド(BlackGoat)に持っていけることになります。

BBM(仮称)はBBQ同様、banana238かoyster243かな。
管理する必要があるデータの大きさで決まると思います。
小さければbanana238、大きければoyster243。

**root ★** · 04/07/02 13:05

というわけで、目的 (>>25) の 3) と 4) を実現しようというのが、
今回の眼目になりますね。

5)は「重くても重いなりに動く」という、現在の路線(LA=100でも一応動きはする)
という方向で、チューニングをすることになるかと。

**FOX ★** · 04/07/02 13:08

現在行っていることは、以下の事だと思っています
right ?

1) フロント三台に携帯からのアクセスを有る程度集めた
2) c-docomo 等が重い状況になっている
3) c-docomo のディスクi/oが処理に追いついていない
4) 当初の目論見どおり BlackGoat を導入して Disk i/o は分離

現在ここ

5) c-docomo の負荷が劇的にさがる　←　期待されること(達成すべきこと)

**root ★** · 04/07/02 13:16

>>28
3)までは概ねcorrect.

現在4)の方法を模索している状態。

◆BFzK/mtqM2 · 04/07/02 13:32

いまのc-othersのdatはNFS？

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 13:35

28-29
3.1)定期的に各鯖から差分ＤＬ
3.2)書き込み後もＤＬ

と妄想してみたり・・・

ギコナビとかちゅ～しゃ両方で一部スレ取得してるからどうにかしたいこの頃
*一部スレ
ものすごい勢いで広告・宣伝を報告するスレ 7
http://qb5.2ch.net/test/read.cgi/sec2chd/1087899804/
【複数スレ】マルチポスト・コピペ報告スレッド11
http://qb5.2ch.net/test/read.cgi/sec2chd/1086698500/
【単独スレ】スクリプト・コピペ報告スレッド8【全板共通】
http://qb5.2ch.net/test/read.cgi/sec2chd/1088531654/
規制人を誘導するスレ3［報告スレではありません］
http://qb5.2ch.net/test/read.cgi/sec2chd/1080130473/
携帯及び●による荒らし報告専用スレッド２
http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/

(^_^;)

**root ★** · 04/07/02 13:59

昨夜やってみたことの簡単なまとめ:

・BlackGoatでフロントエンドと同じ構成のクラシックメニューを動かした
・三人娘ではpoundというプログラムを動かし、単純にBlackGoatにリクエストを
転送するようにした
・その結果、BlackGoatにディスクI/Oを集めることが出来たが、
同時にPHPでの処理もBlackGoatに移ったため、BlackGoatが劇重になった

その結果わかったこと

・対携帯のネットワーク処理だけを別マシンに移す方式ではだめだった

04/07/02 14:04

>>32
むむむさん、それって、失敗の巻きって事ですね。

04/07/02 14:10

うんこ

**root ★** · 04/07/02 14:24

>>32
うん。ということで >>26 なわけだ。

**root ★** · 04/07/02 15:14

NFSでうまくいかなかったのは、statd/lockdを上げていなかったからだとわかりました。
(NFS設定するのなんて昔のSun以来だから、すっかり忘れていた)

で、正しく設定しても、どうもFreeBSDではうまく動かないみたい。
BlackGoat側のrpc.lockdがすごい勢いでCPUを食い、クライアント側(httpd)はハングアップ。

いろいろ調べてみると、どうもFreeBSDのNFS経由でのflockは、かなりいいかげんらしいと。

ということで、NFS路線はどうもやめたほうがいいみたい。
やっぱり、三人娘のクラシックをクラシック改にする必要がありそう。

◆BFzK/mtqM2 · 04/07/02 15:19

じゃあ週末にでもその辺の改造をやってみます。

**root ★** · 04/07/02 15:30

>>37
了解です。

では、blackgoatではProxyモードでApacheを上げておきます。
使い方等は別途。

◆BFzK/mtqM2 · 04/07/02 15:42

了解です。
キャッシュのdelayは黒山羊さんが握るんだよね。

**root ★** · 04/07/02 16:13

>>39
squidのdelay poolsを使えばいいかな。
Apacheのmod_proxyではできるんだっけ。

**root ★** · 04/07/02 16:18

>>40
あ、時間って指定できないかも。< squid

ありものでできるか別途調べた上で、なければ何か考えないといかんかな。

あらまほしい動作は、datが更新されていた場合でも
120秒は読み込まない、ということですよね。

◆BFzK/mtqM2 · 04/07/02 16:45

そうですね。
ちゃんとやるには差分とDelayを黒山羊さんに実装しないといけませんね。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 17:37

質問です(^_^;)
１　今回の失敗の巻は
　・BGにクラシックメニューを設置
　・受付嬢をリバースプロキシに変更
　だったのかな？

２　リバースプロキシはBGからのパケットをバッファして送出してたのかな？
　　つまり、BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
　　そういう仕様になってたのかって話です(^_^;)

**root ★** · 04/07/02 18:12

>>43
1 Yes. (私としては正直「予想通りの失敗」です)

2 なかなかBGから携帯側に送り返すべき結果が来ない状態でした。
つまり、三人娘はすかすかで、BG側が過負荷でパンク。
ということで、BG=>三人娘の送出が詰まっていたわけではなく、
BG側の処理が詰まっている状態と。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:14

>44
えーっと(^_^;)どういう状態だったかってのは結果なので、それはそれでいいんですが
問題は
＞BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
＞そういう仕様になってたのかって話です(^_^;)
これなんですよ。もし、そういう仕様になってなかったら、BGが重くなるのは当然だと思えるので(^_^;)

**root ★** · 04/07/02 18:14

クラシックメニューのPHPでの処理は、それなりにコスト高いです。
これと純粋なディスクI/O処理を分離したいというのが、今模索している方向かなと。

**root ★** · 04/07/02 18:16

>>45
リバースプロキシはpoundをとりあえずほぼデフォルトで使いました。
この場合どうなるのかな。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:20

>47
そこを検証しないと、結果だけ見て動いても問題は解決に近づかないと思われ(^_^;)
携帯側の低速なネットワークに対してバッファするのがフロントエンド
データをキャッシュすることで、フロントエンドのI/Oの負荷を下げ
かつ２ｃｈ側の負荷を携帯システムから分離するのがバックエンド
という役割分担をしたいわけなんだけど
もし、フロントエンドがパケット単位で受け取り＞送出（つまりストリーミングな処理）をしていたら
今までフロントエンドが単独で処理してたより、状況が悪くなりですよ。
１　フロント、バックに分けたことによるオーバーヘッド
２　フロント３台の処理を、バック１台にまとめたことによる負荷
３　ボトルネックとなったバックエンドからの低速なアクセスによる２ｃｈ全体の負荷

04/07/02 18:23

プロキシってのはそういうモンじゃないっしょ

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:23

少なくともフロントエンドは、携帯に送出する速度に関わらず
バックエンドから一気にデータを受け取ってしまわないと
携帯への送出速度に同期してバックエンドからデータを受け取ってしまうと
バックエンドが破綻するのはあたりまえといえばあたりまえの結果かと思います(^_^;)

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:24

>49
あ(^_^;)おいらの認識が間違ってるってのは普通のことです
なので「質問」なのですよ。

◆BFzK/mtqM2 · 04/07/02 18:24

これから負荷が重くなる時間なので、バックエンドにクラシックメニューにして、
プロキシのチューニングをまずやってみるのが先決かな？

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:41

理想を言えば
バックエンドはデータのキャッシュ、差分取得、必要分の送出の３つだけを黙々とこなして
フロントエンドは、データ送出バッファとread.cgi（およびその付加機能）を担当できればいいんだけどね・・・・(^_^;)
バックエンドにユーザーインターフェースとかが入ってくるのは
負荷集中を生み出すだけだと思われ。

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 18:44

>>50
だあね。そのやり方だと結局今までと変わらないし。
フロント⇔バック間の処理は携帯の速度と非同期で
動かないと成功しないでしょう。

携帯　　→　　フロント　　　　　バック
　　リクエスト　　　　 (PORT閉)

携帯　　－　　フロント　　→　　バック
　　 TIME_WAIT　　　　リクエスト

携帯　　－　　フロント　　←　　バック
　　 TIME_WAIT　　　　　DAT転送

携帯　　－　　フロント　　　　　バック
　　 TIMEWAIT PHP処理　(PORT閉)

携帯　　←　　フロント　　　　　バック
　　 cHTML転送　　　　 (PORT閉)

携帯　　　　　フロント　　　　　バック
　　 (PORT閉) 　　　　 (PORT閉)

**root ★** · 04/07/02 18:47

>>53
そうですね。というか当初からそれしかないと思われ。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:55

>55
ですよね(^_^;)
で、リバースプロキシはそういう動作をするものなんでしょうか？
↑実はどういうものか全然わかってなかったりする(^_^;)

**▲ 某ソレ511** · 04/07/02 18:57

リバースプロキシの検索結果のうち日本語のページ約 1,900 件中 1 - 50 件目 (0.43 秒)

http://e-words.jp/w/E383AAE38390E383BCE382B9E38397E383ADE382ADE382B7.html

**root ★** · 04/07/02 18:57

>>54
昨日やったのはこれですね。★のところが重いわけです。

ちなみに現在の各フロントエンドので発生しているディスク書き込み量は、
ピーク時のgame6の倍以上、負荷がやや高い時のlive8ぐらいあります。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/io/

携帯　　→　　フロント　　　　　バック
　　リクエスト　　　　 (PORT閉)

携帯　　－　　フロント　　→　　バック
　　 TIME_WAIT　　　　リクエスト

携帯　　－　　フロント　　←　　バック
　　 TIME_WAIT　　　　　★必要に応じdatを取得・datを保存・PHP処理・結果転送

携帯　　－　　フロント　　　　　バック
　　 TIMEWAIT そのまま転送　(PORT閉)

携帯　　←　　フロント　　　　　バック
　　 cHTML転送　　　　 (PORT閉)

携帯　　　　　フロント　　　　　バック
　　 (PORT閉) 　　　　 (PORT閉)

**FOX ★** · 04/07/02 18:58

>>57
このスレッドに記録するのが目的だったり

**root ★** · 04/07/02 19:03

>>56
そういう動作はしませんです。

今回の実験は、前スレのこれ↓を受けた試験だったということで。

960 名前： ◆BFzK/mtqM2 [sage] 投稿日：04/06/30 18:23 ID:vQ7rJwVR
クラシック本体をバックエンドに持ってきて、フロントを介して携帯とやりとりするのかな？

961 名前：root ★[sage] 投稿日：04/06/30 20:22 ID:???
>>960
はい、最初(Tigerサーバ/w SCSI stripeが入る前提だったころ)は、それも考えていました。
で、各フロントエンドは、リバースプロキシをすると。

しかし、今回入るバックエンドはbananaサーバです。
ということで、PHPをバックエンドではあんまり動かしたくないかもなぁと。

ただ、どっちの方式がいいかは、やってみないとわからないところがあります。

1)方式1

・フロントエンドはクラシック(改)
・バックエンドはApacheのプロキシ+キャッシュ

2)方式2

・フロントエンドはApacheのリバースプロキシ
・バックエンドはクラシック

962 名前： ◆BFzK/mtqM2 [sage] 投稿日：04/06/30 20:33 ID:vQ7rJwVR
まずは、負荷かかるかもしれないが、（2）を試して、
その間に（1）の準備をしましょうか。

963 名前：root ★[sage] 投稿日：04/06/30 20:47 ID:???
>>962
そうしますか。
なら、一番苦しいとこからやんないと意味ないですね。
c-auやc-othersは何とかなってるから、自動的にあれかぁ。

**▲ 某ソレ511** · 04/07/02 19:05

いやこのリンク先、単なるIT用語辞典なんだけどね、、
さすがに用語の意味くらいなら検索したほうがいいんじゃないかと思って。
IT用語辞典が消えることはインターネットがある限りないと思うし。
それをどのように適用するかなら書いても価値があると思うんですけど、、

とりあえずかいつまんで書いておくと、
　外部からネットワーク内部へのアクセスをする際に通されるもののことで、
　中継時にURLやパケットの内容を保存することでセキュリティを強化したり
　アクセス数の多いデータをキャッシュとして保存することにより高速化したりできる。（←今回はこれが目的かな）
　内部から外部へ接続するプロクシの反対なので「リバース」がつくと言われている。
こんなところかな、

**root ★** · 04/07/02 19:10

で、もしバックエンドのPHP処理やディスクI/Oがおなかいっぱいで、
かつクラシックメニューが簡単には改造できないとしたら、
以下の構成もありかなと。

フロント <=> バックエンド1(クラシック)
　　　　　<=> バックエンド2（クラシック)
　　　　　<=> バックエンド3(クラシック)

フロント<=>バック間はリバースプロキシでURLを見てロードバランスする。
(これは簡単に設定できます)

つまり、ディスクI/OやPHPをやる人の負担を単に1/3に薄めると。

**root ★** · 04/07/02 19:12

で、>>62 の構成は今の路線(今はURLを見るのではなくて、au/docomo/othersで割っている)
で、これを細かく割ると。

ただ、どうみてもこれは筋悪だし、本格的な解決になってないというのがここの判断かなと。
ということで、>>53 >>54 方式かなと。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 19:13

>62
それだと携帯ユーザーが満足できるだけバックエンドを入れた時点で２ｃｈ側の負荷が・・・・(^_^;)
フロントいっぱい＞バックエンド少し＞２ｃｈ
という分散モデルにならないと・・・・(^_^;)

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 19:14

まー、外野であれでなと、これでないとと騒ぐのは簡単なんですけどね(^_^;)

**root ★** · 04/07/02 19:16

>>64
ということで世間的には、バックエンド1,2,3を
別途用意した同じProxyサーバにつなぐわけです。はい。

**root ★** · 04/07/02 19:18

ただ今回は、もうめざす路線は概ね合意できている気がするので、

・携帯からの受付・PHP処理・dat/subject.txtリクエスト…フロントエンド
・フロントからのリクエスト受理・dat/subject.txt取得・管理…バックエンド

その形をめざして動くことでよいのではないかと。

**root ★** · 04/07/02 22:07

blackgoat、これからちょっとファイルシステムのチューニングをしてみます。

**動け動けウゴウゴ２ちゃんねる** · 04/07/02 22:36

Pekoでやったようなメモリ周りのチューニングはいかがでしょ

**root ★** · 04/07/02 22:56

blackgoat、チューニングできた。
ちょっと、c-docomoでためしてみます。

**root ★** · 04/07/02 23:02

c-docomo => blackgoatを復活させた。
さて、どこまで上がるか。< blackgoat

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 00:01

今のところいい感じ？
ttp://mumumu.mu/mrtg/mrtg-rrd.cgi/load/c-docomoload.html

**root ★** · 04/07/03 00:03

ccdを使って、blackgoatのディスクをストライピングにしてみた。
ちゃんとad0とad1にほぼ均等にアクセスがいくようになった模様。

ただし、ディスクは確かに楽になったけど、LAは改善されてないみたい。

ただ、今はまだ無制限に受け付けるので、
接続が目いっぱいまで使われてしまうことも、原因にあるかなと。

httpdを24, 32, 48, 64, 96, 128, 160 と変えて試してみたけど、
24の状態で既にPHP処理だけでCPUはめいっぱいみたい。
ほとんどのhttpdはRUN状態(PHP処理中)になっています。

で、マァヴさんが言っていた状態になっているかどうか(BlackGoat側の送信部分が
ふん詰まり状態になっているか)をnetstatコマンドなどで確認してみましたが、
いずれの状態もバック=>フロントへの送信そのものは速やかに終わっていました。

つまり、BlackGoat側からフロント側への送信はすばやく終わっていて、
BlackGoat側で送信そのものに詰まっている状態は、観測されていませんでした。

コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。
接続数を多くするとリニアにLAが上がっていく状態。
実はへたすると、PHPの処理の方がディスクI/O処理よりもコストが高いのかも。

自宅に帰ったらフロントエンド側を調整して、接続数制限を入れてみるか。

**root ★** · 04/07/03 00:05

>>72
そっちは、ねぇ。PHP処理とディスクI/O処理をしない状態になるから、軽くなるんですよ。
こっちが、重要。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/blackgoatload.html

実際のDoCoMoのユーザさんのレスポンス具合はどうかなと。
たぶん、今は昨日までとあんまり変わらないはず。

**FOX ★** · 04/07/03 00:07

>コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。

って、BlackGoat の話しですか?

であるならば、
まずは何よりも先に「本来の目論見である、DISK i/o だけ」にするのが先かと、

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 00:09

>>74
あんまり変わらないですね。ただもともと接続速度が遅いので
そんなに気になりませんが。
FOMAの人は気になるレベルかもしれません。

**root ★** · 04/07/03 00:14

>>75
はい、その通りですね。

今回のテストでは「PHP処理とディスク処理のどちらがより苦しいか」の
再検証と、BlackGoatをディスクI/Oに特化させるための準備
(BlackGoatへのストライピングの導入&テスト)をやっていました。

ということで、BlackGoatのディスクをストライプ構成にできました。
(FreeBSDには標準でその機能があります)

/etc/ccd.conf に以下のように書くと、ストライプ構成にできます。

# ccd ileave flags component devices
ccd0 64 none /dev/ad0s1f /dev/ad1s1d

/dev/ccd0を/homeにmountしました。
/homeに書き込むと、ad0とad1に均等にI/Oがかかることを確認しています。
(これの確認には、実際に高い負荷をかけてみることが必要なので)

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 00:15

>>73
＞実はへたすると、PHPの処理の方がディスクI/O処理よりもコストが高いのかも。
よーしこうなったらkage.cgi（仮）をＣで作っちまおう

**root ★** · 04/07/03 00:18

んで、ディスクI/Oは相当楽になりました。
ccd化はパフォーマンス向上にかなり効果ありそうです。
しばらく動かして問題なければ、機を見てフロントエンドの/homeもこの構成にしようかなと。

ここはバックアップ要らないということで、バックアップ用ディスクをつぶしました。

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 00:18

いまN900iからｱｸｾｽしています。
1ﾍﾟｰｼﾞ開くのに30秒くらいかかります。
ヤフーは5秒です。

**root ★** · 04/07/03 00:25

>>76 >>80
どうも。
>>73 >>74 でも書きましたが、今までのこの時間と概ね同じか。
LAは少し低くなりましたが、あんまり変わりませんね。
100超えていたのが80台になったぐらい(このぐらいは誤差の範疇)。

つまり、ストライピングによる I/O性能の向上では、
PHP処理の重さは埋めきれなかったと。

ということで、>>75 であることが改めて裏付けられたと。
(もしこれで軽くなっていたら、I/Oがボトルネックだったことになる)

**FOX ★** · 04/07/03 00:32

Front - BlackGoat 間の通信に何を使えば一番いいのかはわかりませんが
一つの案としては、素直に http を使うのもありだと思っています

つまり(予測ですが) Front の２ちゃんねるのサーバ群への dat 要求を
現在 http で行っている。その部分を BlackGoat に書き直す(たぶん private IPs)
だけで front 側の修正は ok なはず

んで、　BlackGoat 側でのfrontとの会話部分を新たに開発すれば
以上終わりだと思います。この辺でいろいろな方法があると思う。

**root ★** · 04/07/03 00:37

私も、概ねそう思っています(>>82 の前半部分)。
単純にシンプルな形でいいんじゃないかなと。

基本的には、120secのディレイをうまく処理できるProxyサーバみたいなものがあれば、
いいんじゃないなと思っています。

あとは、クラシックメニュー側で持ってきたdatファイルをopen()とかstat()とかしていたり、
追加書き込みをしていたりするところがあると思うので、
それへの対応が >>82 の後半部分になるのかなと。

**root ★** · 04/07/03 00:40

で、ぐちというか、ひとりごとを。

最初からTiger+ストライピングだったら、うんうんうなりながらccdとかvinumとか
調べたりしませんでした。

つまり、いわゆるただ働きモデルでストライピングは実現できたわけで。
しかし、どきどきしながらパーティションのつけかえをしたり、
リモートでccdの設定したりして、なかなかスリリングで楽しかったです(w。

ただし、カネを使ってハードウェアでやるストライピングには、もちろんかないませんが。

**FOX ★** · 04/07/03 05:39

1) 受付嬢から必要な時に必要なデータ(.dat .txt) を BlackGoat から取得する
　　この場合、受付嬢はデータを溜め込むとか何もしない
　　もしかしたらディレイ値 0sec で動かせばそうなるのかな?(中見たことないので推測)
　　ただし２ちゃんねるの各サーバから取得するのではなく
　　BlackGoat から全部取得する

2) BlackGoat は受付嬢からの要求が来たら、キャッシュしつつ
　　２ちゃんねるの各サーバから実際に持ってくる
　　　・初めてのとき or 指定された delay値を超えた場合は実際に取りにいく(差分取得)
　　　・そうでないときは自HDに溜め込んでいるデータを帰す。

3) 　この二つを達成するために受付嬢 - BlackGoat の間にはデータやり取りの
　　決め事を作らなければならない。
　　　・ http を使ってやり取りするとしたらどんな方法?
　　　・ cgi にしちゃう? (これが第一歩かも・・・)

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 07:06

２ちゃんを月１００～３００円くらいの有料コンテンツにして
鯖増強してほしい。

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 07:43

>>86
有料にしても同じ人数が集まるならいいが
確実に人が減るので今のような有益な情報が集まらなくなる。
するとさらに人が減る
2chあぼーん

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 09:37

いや半分ぐらいになった方が良いかもしれん。
あとから入ってくる人はアホみたいに居るし。

ってスレ違いだよ、頑張れオレ。

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 11:09

携帯（ﾊﾟｹﾎ）での観覧だけ有料にするとか？
ｽﾚ違い。。。

**未承諾広告※** ◆TWARamEjuA · 04/07/03 12:19

http://c-au.2ch.net/_service/20040703.txt
ちょと変です(苦笑)

**ミラー名無しさん** · 04/07/03 15:28

0000000 067 066 063 063 012 000 000 000 000 000 000 000 000 000 000 000
0000000 7 6 3 3 \n \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000010 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
00007d0 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 062
00007d0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 2
00007e0 060 060 064 057 060 067 057 060 063 040 060 064 072 063 060 072
00007e0 0 0 4 / 0 7 / 0 3 0 4 : 3 0 :
あ、ぬる（ry

リブート前のログは正常なんですけど、なんででしょうね。
http://www6.ocn.ne.jp/~usada/c-au/20040703.0.txt 但し2:30迄

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 16:07

c.2ch不具合報告総合スレ
http://qb5.2ch.net/test/read.cgi/operate/1088828988/l50

◆EA.clAssIc · 04/07/03 18:16

いままで直接各ｻｰﾊﾞに
GET /operate/dat/1086680380.dat HTTP/1.1
でﾘｸｴｽﾄしていたものを、
BGの指定ﾎﾟｰﾄ経由(proxy)で
GET http://qb5.2ch.net/operate/dat/1086680380.dat HTTP/1.1
とﾘｸｴｽﾄするように変えてみますか?

**FOX ★** · 04/07/03 18:25

ふむふむ、で

・受付嬢は DIsk i/o しなくなる

ができるなら、それがいいです。
そして BlackGoat はそのまま各サーバから
データを持ってくる状態になっているのだろうか?
それであるならば、あとはその部分を改良すれば良いだけな気がする。

>>93 をやって何がわかりどんな期待が出来るか。。。

1) c-docomo 一台でフロントとしての実力がわかる
2) BlackGoat をどの様に改善すればよいかの情報がとれる
ただし
3) BlackGoat がフロントからの要求を全て直接各２ちゃんねるのサーバに
　　問い合わせるので、各サーバの負荷はあがる

受付嬢の要求仕様は >>93 をやる事で完成だと思う

**動け動けウゴウゴ２ちゃんねる** · 04/07/03 18:25

>>91
ｶﾞ(ry

◆EA.clAssIc · 04/07/03 18:42

>>94 FOXさん、
では、ちょっとやってみます。

･受付嬢変更点
1) dat、subjectのﾘｸｴｽﾄ先をBGへ(PROXY経由)
2) ｷｬｯｼｭの作成を停止
3) 2)より、ﾃﾞｨﾚｲは実質的に0secへ(ﾃﾞｨﾚｲ処理はBG側に任せることになります)

BGは現段階でproxyとして動作可能なのでしょうか?
もし動作可能であるなら、接続の為のport等の情報をﾒｰﾙして下さると幸いです。　>>rootさん

◆BFzK/mtqM2 · 04/07/04 02:19

とりあえず、キャッシュ生成しないバージョンを入れてみました。
ちょっと、バグがあるけど（＾＾；

現在、ディレイなしで直接各サーバからdatを読み込み、それを処理するようにしてみました。
PROXYはとりあえずなしです。

◆BFzK/mtqM2 · 04/07/04 02:35

2004/07/04 01:41:21 LA= 1:42AM up 22:18, 0 users, load averages: 92.06, 93.51, 93.92
2004/07/04 01:50:02 LA= 1:50AM up 22:26, 0 users, load averages: 93.77, 94.52, 94.51
2004/07/04 02:01:19 LA= 2:01AM up 22:37, 0 users, load averages: 93.92, 93.44, 93.98
2004/07/04 02:10:00 LA= 2:10AM up 22:46, 0 users, load averages: 95.25, 94.00, 93.86
2004/07/04 02:20:00 LA= 2:20AM up 22:56, 0 users, load averages: 1.91, 21.91, 53.72
2004/07/04 02:30:00 LA= 2:30AM up 23:06, 0 users, load averages: 1.39, 4.18, 27.20

LAは劇的に低くなったがレスポンスは相変わらずですね。。。。

◆BFzK/mtqM2 · 04/07/04 02:45

c-docomo
2004/07/04 02:40:00 LA= 2:40AM up 23:16, 0 users, load averages: 1.30, 2.15, 14.43

c-au
2004/07/04 02:40:00 LA= 2:40AM up 22:10, 0 users, load averages: 20.86, 23.19, 23.66

c-others
2004/07/04 02:40:00 LA= 2:40AM up 21:55, 0 users, load averages: 0.59, 0.52, 0.51

うーん、c-docomoはなんでLAがこんなに低いんだろう。。。。

◆BFzK/mtqM2 · 04/07/04 02:46

とりあえず、しばらくこれで動かそうかな。。。。。