【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ではできるんだっけ。 ■ このスレッドは過去ログ倉庫に格納されています