【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part2 大黒埠頭
前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/ ●はPCと共通で構わないのでは?
携帯上で購入可にするのは難しいのでしょうかねやはり http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/597
597 :だいこん ★ :04/07/01 15:36 ID:???
毎日五個くらい携帯規制リストに追加している気がする。。。
リストが大きくなると、bbs.cgi が遅くなるというか負荷が上がるというか
処理が重くなるというか、、、 >>9
携帯用判定文字列ってどんなかんじなんでしたっけ。
DNSにうまく載せられるのかしら。 私はパソコンがないので携帯から2ちゃんを閲覧しています。
携帯から閲覧できる機能は、とてもありがたいのですが、
そのせいで2ちゃんねるに負担をかけたり、以前のような閉鎖危機に陥ったりするのは嫌です。
サーバーの負担になるのであれば、携帯からの閲覧機能は無くてもいいです。
悲しいけど、2ちゃんねるが無くなるのはもっと悲しい。 >>11
俺はPCオンリーのユーザーだが君みたいな人にはなんとかしてあげたい >>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の "_" 以外は大丈夫そうですねー 規制するのは端末固有情報だから、bbs.cgi叩きにいくときしか出さないはず。 そうだ。せっかく占有のスイッチでつながってるんだから、
datディレクトリをNFSするというのはどうだろ。
あとで、やってみよう。 use Digest::md5;
:
:
sub Get_Mobile_ID($) {
my $Mobile_ID = Digest::md5->new;
$Mobile_ID->add(shift);
return $Mobile_ID->base64digest;
}
:
:
DispError('ERROR!', '寄生虫')
if join( '.', unpack 'C4', sprintf qq|%s.bbm.2ch.net|, Get_Mobile_ID($ENV{HTTP_USER_AGENT})) =~ /^127.0.0/ ;
UA をそのまま MD5 にして bbm(仮名) 送りはちょと強引かな?(^-^;) 確かにNFSにするのが一番簡単ですね。
それならばクラシック側は変更もいらないですね。 >>16
datの下だけNFSにすると「キャッシュが作成できません」と言われるなぁ。
たぶん、何か呪文が必要なのかも。
これ以上は中の人に聞かないと。 >>18
単に、datの下をNFSに(動かしながら)するんじゃだめなんでしたっけ。
何か設定が必要なんだっけか。 うーむ、NFSじゃなければいきなりmvしてもいけるみたい。
だとすると私の設定の問題か。 >>21 は勘違いでした。どうもいきなりmvするんじゃだめかも。
結局 >>19 か。 パーミッションはどうなっていますか?
777ならキャッシュ作れると思うんだけどな〜 出来れば「目的」を書いてから「手段」(たとえば >>21)を書いていただけると
とてもありがたいです、
なにをしたいんだろう
そしてそれは何が目的なんだろう
結果どうなったんだろう マーリンルージュ作戦の目的をおさらいしよう。
携帯からのアクセスは速度が非常に遅い等の特徴があり
2ちゃんねるのサーバ全体のお荷物となっている。
受付嬢を置く等でそれが原因となる負荷
速度が遅いのを2ちゃんねるの各サーバへ
直接影響を及ぼさないようにダム(バッファー)になって
動作する、またディレイ値を設けることで全体の負荷もさげようです。
つまり
1) ダム(バッファー)になり通信速度の遅さを吸収し、全サーバを助ける。
2) ディレイ値を設けて、全体のアクセスを減らし、全サーバを助ける。
3) フロントのマシンは DSIK IO をしないで、通信に専念
4) BlackGoat はdatのキャッシング(遅延値=可変)に専念
5) どんなにアクセスが来ても二ヶ月はリブートなしで動くように、
大黒埠頭は
BBM等の各種一元管理+四台目以降の増設方法(テクニカル、ポリティカル、エコノミカル)です
>>24
今回の目的は、前スレにもありますが、
・PHPによる各種処理
・datキャッシュへのディスクI/O
を、分割するためのものです。
今回のNFS化がうまく動けば、現在のクラシックメニューのプログラムを変更せずに、
ディスクI/Oだけをバックエンド(BlackGoat)に持っていけることになります。
BBM(仮称)はBBQ同様、banana238かoyster243かな。
管理する必要があるデータの大きさで決まると思います。
小さければbanana238、大きければoyster243。 というわけで、目的 (>>25) の 3) と 4) を実現しようというのが、
今回の眼目になりますね。
5)は「重くても重いなりに動く」という、現在の路線(LA=100でも一応動きはする)
という方向で、チューニングをすることになるかと。 現在行っていることは、以下の事だと思っています
right ?
1) フロント三台に携帯からのアクセスを有る程度集めた
2) c-docomo 等が重い状況になっている
3) c-docomo のディスクi/oが処理に追いついていない
4) 当初の目論見どおり BlackGoat を導入して Disk i/o は分離
現在ここ
5) c-docomo の負荷が劇的にさがる ← 期待されること(達成すべきこと)
>>28
3)までは概ねcorrect.
現在4)の方法を模索している状態。 昨夜やってみたことの簡単なまとめ:
・BlackGoatでフロントエンドと同じ構成のクラシックメニューを動かした
・三人娘ではpoundというプログラムを動かし、単純にBlackGoatにリクエストを
転送するようにした
・その結果、BlackGoatにディスクI/Oを集めることが出来たが、
同時にPHPでの処理もBlackGoatに移ったため、BlackGoatが劇重になった
その結果わかったこと
・対携帯のネットワーク処理だけを別マシンに移す方式ではだめだった >>32
むむむさん、それって、失敗の巻きって事ですね。 >>32
うん。ということで >>26 なわけだ。 NFSでうまくいかなかったのは、statd/lockdを上げていなかったからだとわかりました。
(NFS設定するのなんて昔のSun以来だから、すっかり忘れていた)
で、正しく設定しても、どうもFreeBSDではうまく動かないみたい。
BlackGoat側のrpc.lockdがすごい勢いでCPUを食い、クライアント側(httpd)はハングアップ。
いろいろ調べてみると、どうもFreeBSDのNFS経由でのflockは、かなりいいかげんらしいと。
ということで、NFS路線はどうもやめたほうがいいみたい。
やっぱり、三人娘のクラシックをクラシック改にする必要がありそう。 >>37
了解です。
では、blackgoatではProxyモードでApacheを上げておきます。
使い方等は別途。 了解です。
キャッシュのdelayは黒山羊さんが握るんだよね。 >>39
squidのdelay poolsを使えばいいかな。
Apacheのmod_proxyではできるんだっけ。 >>40
あ、時間って指定できないかも。< squid
ありものでできるか別途調べた上で、なければ何か考えないといかんかな。
あらまほしい動作は、datが更新されていた場合でも
120秒は読み込まない、ということですよね。 そうですね。
ちゃんとやるには差分とDelayを黒山羊さんに実装しないといけませんね。 質問です(^_^;)
1 今回の失敗の巻は
・BGにクラシックメニューを設置
・受付嬢をリバースプロキシに変更
だったのかな?
2 リバースプロキシはBGからのパケットをバッファして送出してたのかな?
つまり、BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
そういう仕様になってたのかって話です(^_^;) >>43
1 Yes. (私としては正直「予想通りの失敗」です)
2 なかなかBGから携帯側に送り返すべき結果が来ない状態でした。
つまり、三人娘はすかすかで、BG側が過負荷でパンク。
ということで、BG=>三人娘の送出が詰まっていたわけではなく、
BG側の処理が詰まっている状態と。 >44
えーっと(^_^;)どういう状態だったかってのは結果なので、それはそれでいいんですが
問題は
>BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
>そういう仕様になってたのかって話です(^_^;)
これなんですよ。もし、そういう仕様になってなかったら、BGが重くなるのは当然だと思えるので(^_^;) クラシックメニューのPHPでの処理は、それなりにコスト高いです。
これと純粋なディスクI/O処理を分離したいというのが、今模索している方向かなと。 >>45
リバースプロキシはpoundをとりあえずほぼデフォルトで使いました。
この場合どうなるのかな。 >47
そこを検証しないと、結果だけ見て動いても問題は解決に近づかないと思われ(^_^;)
携帯側の低速なネットワークに対してバッファするのがフロントエンド
データをキャッシュすることで、フロントエンドのI/Oの負荷を下げ
かつ2ch側の負荷を携帯システムから分離するのがバックエンド
という役割分担をしたいわけなんだけど
もし、フロントエンドがパケット単位で受け取り>送出(つまりストリーミングな処理)をしていたら
今までフロントエンドが単独で処理してたより、状況が悪くなりですよ。
1 フロント、バックに分けたことによるオーバーヘッド
2 フロント3台の処理を、バック1台にまとめたことによる負荷
3 ボトルネックとなったバックエンドからの低速なアクセスによる2ch全体の負荷 少なくともフロントエンドは、携帯に送出する速度に関わらず
バックエンドから一気にデータを受け取ってしまわないと
携帯への送出速度に同期してバックエンドからデータを受け取ってしまうと
バックエンドが破綻するのはあたりまえといえばあたりまえの結果かと思います(^_^;) >49
あ(^_^;)おいらの認識が間違ってるってのは普通のことです
なので「質問」なのですよ。 これから負荷が重くなる時間なので、バックエンドにクラシックメニューにして、
プロキシのチューニングをまずやってみるのが先決かな? 理想を言えば
バックエンドはデータのキャッシュ、差分取得、必要分の送出の3つだけを黙々とこなして
フロントエンドは、データ送出バッファとread.cgi(およびその付加機能)を担当できればいいんだけどね・・・・(^_^;)
バックエンドにユーザーインターフェースとかが入ってくるのは
負荷集中を生み出すだけだと思われ。 >>50
だあね。そのやり方だと結局今までと変わらないし。
フロント⇔バック間の処理は携帯の速度と非同期で
動かないと成功しないでしょう。
携帯 → フロント バック
リクエスト (PORT閉)
携帯 − フロント → バック
TIME_WAIT リクエスト
携帯 − フロント ← バック
TIME_WAIT DAT転送
携帯 − フロント バック
TIMEWAIT PHP処理 (PORT閉)
携帯 ← フロント バック
cHTML転送 (PORT閉)
携帯 フロント バック
(PORT閉) (PORT閉) >>53
そうですね。というか当初からそれしかないと思われ。 >55
ですよね(^_^;)
で、リバースプロキシはそういう動作をするものなんでしょうか?
↑実はどういうものか全然わかってなかったりする(^_^;) >>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閉) >>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は何とかなってるから、自動的にあれかぁ。 いやこのリンク先、単なるIT用語辞典なんだけどね、、
さすがに用語の意味くらいなら検索したほうがいいんじゃないかと思って。
IT用語辞典が消えることはインターネットがある限りないと思うし。
それをどのように適用するかなら書いても価値があると思うんですけど、、
とりあえずかいつまんで書いておくと、
外部からネットワーク内部へのアクセスをする際に通されるもののことで、
中継時にURLやパケットの内容を保存することでセキュリティを強化したり
アクセス数の多いデータをキャッシュとして保存することにより高速化したりできる。(←今回はこれが目的かな)
内部から外部へ接続するプロクシの反対なので「リバース」がつくと言われている。
こんなところかな、 で、もしバックエンドのPHP処理やディスクI/Oがおなかいっぱいで、
かつクラシックメニューが簡単には改造できないとしたら、
以下の構成もありかなと。
フロント <=> バックエンド1(クラシック)
<=> バックエンド2(クラシック)
<=> バックエンド3(クラシック)
フロント<=>バック間はリバースプロキシでURLを見てロードバランスする。
(これは簡単に設定できます)
つまり、ディスクI/OやPHPをやる人の負担を単に1/3に薄めると。 で、>>62 の構成は今の路線(今はURLを見るのではなくて、au/docomo/othersで割っている)
で、これを細かく割ると。
ただ、どうみてもこれは筋悪だし、本格的な解決になってないというのがここの判断かなと。
ということで、>>53 >>54 方式かなと。 >62
それだと携帯ユーザーが満足できるだけバックエンドを入れた時点で2ch側の負荷が・・・・(^_^;)
フロントいっぱい>バックエンド少し>2ch
という分散モデルにならないと・・・・(^_^;) まー、外野であれでなと、これでないとと騒ぐのは簡単なんですけどね(^_^;) >>64
ということで世間的には、バックエンド1,2,3を
別途用意した同じProxyサーバにつなぐわけです。はい。 ただ今回は、もうめざす路線は概ね合意できている気がするので、
・携帯からの受付・PHP処理・dat/subject.txtリクエスト…フロントエンド
・フロントからのリクエスト受理・dat/subject.txt取得・管理…バックエンド
その形をめざして動くことでよいのではないかと。 blackgoat、これからちょっとファイルシステムのチューニングをしてみます。 Pekoでやったようなメモリ周りのチューニングはいかがでしょ blackgoat、チューニングできた。
ちょっと、c-docomoでためしてみます。 c-docomo => blackgoatを復活させた。
さて、どこまで上がるか。< blackgoat 今のところいい感じ?
ttp://mumumu.mu/mrtg/mrtg-rrd.cgi/load/c-docomoload.html 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処理よりもコストが高いのかも。
自宅に帰ったらフロントエンド側を調整して、接続数制限を入れてみるか。 >>72
そっちは、ねぇ。PHP処理とディスクI/O処理をしない状態になるから、軽くなるんですよ。
こっちが、重要。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/blackgoatload.html
実際のDoCoMoのユーザさんのレスポンス具合はどうかなと。
たぶん、今は昨日までとあんまり変わらないはず。 >コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。
って、BlackGoat の話しですか?
であるならば、
まずは何よりも先に「本来の目論見である、DISK i/o だけ」にするのが先かと、 >>74
あんまり変わらないですね。ただもともと接続速度が遅いので
そんなに気になりませんが。
FOMAの人は気になるレベルかもしれません。 >>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がかかることを確認しています。
(これの確認には、実際に高い負荷をかけてみることが必要なので) >>73
>実はへたすると、PHPの処理の方がディスクI/O処理よりもコストが高いのかも。
よーしこうなったらkage.cgi(仮)をCで作っちまおう
んで、ディスクI/Oは相当楽になりました。
ccd化はパフォーマンス向上にかなり効果ありそうです。
しばらく動かして問題なければ、機を見てフロントエンドの/homeもこの構成にしようかなと。
ここはバックアップ要らないということで、バックアップ用ディスクをつぶしました。 いまN900iからアクセスしています。
1ページ開くのに30秒くらいかかります。
ヤフーは5秒です。 >>76 >>80
どうも。
>>73 >>74 でも書きましたが、今までのこの時間と概ね同じか。
LAは少し低くなりましたが、あんまり変わりませんね。
100超えていたのが80台になったぐらい(このぐらいは誤差の範疇)。
つまり、ストライピングによる I/O性能の向上では、
PHP処理の重さは埋めきれなかったと。
ということで、>>75 であることが改めて裏付けられたと。
(もしこれで軽くなっていたら、I/Oがボトルネックだったことになる) Front - BlackGoat 間の通信に何を使えば一番いいのかはわかりませんが
一つの案としては、素直に http を使うのもありだと思っています
つまり(予測ですが) Front の 2ちゃんねるのサーバ群への dat 要求を
現在 http で行っている。その部分を BlackGoat に書き直す(たぶん private IPs)
だけで front 側の修正は ok なはず
んで、 BlackGoat 側でのfrontとの会話部分を新たに開発すれば
以上終わりだと思います。この辺でいろいろな方法があると思う。
私も、概ねそう思っています(>>82 の前半部分)。
単純にシンプルな形でいいんじゃないかなと。
基本的には、120secのディレイをうまく処理できるProxyサーバみたいなものがあれば、
いいんじゃないなと思っています。
あとは、クラシックメニュー側で持ってきたdatファイルをopen()とかstat()とかしていたり、
追加書き込みをしていたりするところがあると思うので、
それへの対応が >>82 の後半部分になるのかなと。
で、ぐちというか、ひとりごとを。
最初からTiger+ストライピングだったら、うんうんうなりながらccdとかvinumとか
調べたりしませんでした。
つまり、いわゆるただ働きモデルでストライピングは実現できたわけで。
しかし、どきどきしながらパーティションのつけかえをしたり、
リモートでccdの設定したりして、なかなかスリリングで楽しかったです(w。
ただし、カネを使ってハードウェアでやるストライピングには、もちろんかないませんが。 1) 受付嬢から 必要な時に必要な データ(.dat .txt) を BlackGoat から取得する
この場合、受付嬢はデータを溜め込むとか何もしない
もしかしたら ディレイ値 0sec で動かせばそうなるのかな?(中見たことないので推測)
ただし2ちゃんねるの各サーバから取得するのではなく
BlackGoat から全部取得する
2) BlackGoat は受付嬢からの要求が来たら、キャッシュしつつ
2ちゃんねるの各サーバから実際に持ってくる
・初めてのとき or 指定された delay値を超えた場合は実際に取りにいく(差分取得)
・そうでないときは自HDに溜め込んでいるデータを帰す。
3) この二つを達成するために 受付嬢 - BlackGoat の間にはデータやり取りの
決め事を作らなければならない。
・ http を使ってやり取りするとしたらどんな方法?
・ cgi にしちゃう? (これが第一歩かも・・・)
2ちゃんを月100〜300円くらいの有料コンテンツにして
鯖増強してほしい。 >>86
有料にしても同じ人数が集まるならいいが
確実に人が減るので今のような有益な情報が集まらなくなる。
するとさらに人が減る
2chあぼーん いや半分ぐらいになった方が良いかもしれん。
あとから入ってくる人はアホみたいに居るし。
ってスレ違いだよ、頑張れオレ。 携帯(パケホ)での観覧だけ有料にするとか?
スレ違い。。。 ■ このスレッドは過去ログ倉庫に格納されています