X



トップページ運用情報
990コメント321KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001FOX ★
垢版 |
04/07/01 13:55ID:???
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。

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

Love Affair 作戦。
Part2 大黒埠頭

前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/
0002げろっぴ ◆/lQMO72QVo
垢版 |
04/07/01 13:56ID:+0JUwbaT
ヽ(・∀・)ノ ウンコー!!
0005動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/01 17:46ID:mRkDCG58
5
0006動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/01 20:18ID:K0wXbJeg
6
0010root ★
垢版 |
04/07/01 23:55ID:???
>>9
携帯用判定文字列ってどんなかんじなんでしたっけ。
DNSにうまく載せられるのかしら。
0011動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/02 02:24ID:EzlyTduU
私はパソコンがないので携帯から2ちゃんを閲覧しています。
携帯から閲覧できる機能は、とてもありがたいのですが、
そのせいで2ちゃんねるに負担をかけたり、以前のような閉鎖危機に陥ったりするのは嫌です。
サーバーの負担になるのであれば、携帯からの閲覧機能は無くてもいいです。
悲しいけど、2ちゃんねるが無くなるのはもっと悲しい。
0015 ◆BFzK/mtqM2
垢版 |
04/07/02 10:08ID:WZectPEP
規制するのは端末固有情報だから、bbs.cgi叩きにいくときしか出さないはず。
0016root ★
垢版 |
04/07/02 10:33ID:???
そうだ。せっかく占有のスイッチでつながってるんだから、
datディレクトリをNFSするというのはどうだろ。

あとで、やってみよう。
0017未承諾広告※ ◆TWARamEjuA
垢版 |
04/07/02 11:01ID:yuD5OMA2
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(仮名) 送りはちょと強引かな?(^-^;)
0018 ◆BFzK/mtqM2
垢版 |
04/07/02 12:11ID:WZectPEP
確かにNFSにするのが一番簡単ですね。
それならばクラシック側は変更もいらないですね。
0019root ★
垢版 |
04/07/02 12:17ID:???
>>16
datの下だけNFSにすると「キャッシュが作成できません」と言われるなぁ。
たぶん、何か呪文が必要なのかも。
これ以上は中の人に聞かないと。
0020root ★
垢版 |
04/07/02 12:17ID:???
>>18
単に、datの下をNFSに(動かしながら)するんじゃだめなんでしたっけ。
何か設定が必要なんだっけか。
0021root ★
垢版 |
04/07/02 12:19ID:???
うーむ、NFSじゃなければいきなりmvしてもいけるみたい。
だとすると私の設定の問題か。
0022root ★
垢版 |
04/07/02 12:24ID:???
>>21 は勘違いでした。どうもいきなりmvするんじゃだめかも。
結局 >>19 か。
0023 ◆BFzK/mtqM2
垢版 |
04/07/02 12:29ID:WZectPEP
パーミッションはどうなっていますか?
777ならキャッシュ作れると思うんだけどな〜
0024FOX ★
垢版 |
04/07/02 12:31ID:???
出来れば「目的」を書いてから「手段」(たとえば >>21)を書いていただけると
とてもありがたいです、

なにをしたいんだろう
そしてそれは何が目的なんだろう
結果どうなったんだろう
0025FOX ★
垢版 |
04/07/02 12:49ID:???
マーリンルージュ作戦の目的をおさらいしよう。

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

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

つまり

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

大黒埠頭は
BBM等の各種一元管理+四台目以降の増設方法(テクニカル、ポリティカル、エコノミカル)です
0026root ★
垢版 |
04/07/02 13:00ID:???
>>24
今回の目的は、前スレにもありますが、

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

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

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

BBM(仮称)はBBQ同様、banana238かoyster243かな。
管理する必要があるデータの大きさで決まると思います。
小さければbanana238、大きければoyster243。
0027root ★
垢版 |
04/07/02 13:05ID:???
というわけで、目的 (>>25) の 3) と 4) を実現しようというのが、
今回の眼目になりますね。

5)は「重くても重いなりに動く」という、現在の路線(LA=100でも一応動きはする)
という方向で、チューニングをすることになるかと。
0028FOX ★
垢版 |
04/07/02 13:08ID:???
現在行っていることは、以下の事だと思っています
right ?

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

現在ここ

5) c-docomo の負荷が劇的にさがる ← 期待されること(達成すべきこと)
0029root ★
垢版 |
04/07/02 13:16ID:???
>>28
3)までは概ねcorrect.

現在4)の方法を模索している状態。
0031動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/02 13:35ID:dzcCghrk
28-29
3.1)定期的に各鯖から差分DL
3.2)書き込み後もDL

と妄想してみたり・・・



ギコナビとかちゅ〜しゃ両方で一部スレ取得してるからどうにかしたいこの頃
*一部スレ
ものすごい勢いで広告・宣伝を報告するスレ 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/
携帯及び●による荒らし報告専用スレッド2
http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/

(^_^;)
0032root ★
垢版 |
04/07/02 13:59ID:???
昨夜やってみたことの簡単なまとめ:

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

その結果わかったこと

・対携帯のネットワーク処理だけを別マシンに移す方式ではだめだった
0033 [―{}@{}@{}-] 動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/02 14:04ID:J4AKDA2N
>>32
むむむさん、それって、失敗の巻きって事ですね。
0034 [―{}@{}@{}-] 動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/02 14:10ID:J4AKDA2N
うんこ
0036root ★
垢版 |
04/07/02 15:14ID:???
NFSでうまくいかなかったのは、statd/lockdを上げていなかったからだとわかりました。
(NFS設定するのなんて昔のSun以来だから、すっかり忘れていた)

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

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

ということで、NFS路線はどうもやめたほうがいいみたい。
やっぱり、三人娘のクラシックをクラシック改にする必要がありそう。
0037 ◆BFzK/mtqM2
垢版 |
04/07/02 15:19ID:WZectPEP
じゃあ週末にでもその辺の改造をやってみます。
0038root ★
垢版 |
04/07/02 15:30ID:???
>>37
了解です。

では、blackgoatではProxyモードでApacheを上げておきます。
使い方等は別途。
0039 ◆BFzK/mtqM2
垢版 |
04/07/02 15:42ID:WZectPEP
了解です。
キャッシュのdelayは黒山羊さんが握るんだよね。
0040root ★
垢版 |
04/07/02 16:13ID:???
>>39
squidのdelay poolsを使えばいいかな。
Apacheのmod_proxyではできるんだっけ。
0041root ★
垢版 |
04/07/02 16:18ID:???
>>40
あ、時間って指定できないかも。< squid

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

あらまほしい動作は、datが更新されていた場合でも
120秒は読み込まない、ということですよね。
0042 ◆BFzK/mtqM2
垢版 |
04/07/02 16:45ID:WZectPEP
そうですね。
ちゃんとやるには差分とDelayを黒山羊さんに実装しないといけませんね。
0043マァヴ ◆jxAYUMI09s @マァヴ ★
垢版 |
04/07/02 17:37ID:???
質問です(^_^;)
1 今回の失敗の巻は
 ・BGにクラシックメニューを設置
 ・受付嬢をリバースプロキシに変更
 だったのかな?

2 リバースプロキシはBGからのパケットをバッファして送出してたのかな?
  つまり、BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
  そういう仕様になってたのかって話です(^_^;)
0044root ★
垢版 |
04/07/02 18:12ID:???
>>43
1 Yes. (私としては正直「予想通りの失敗」です)

2 なかなかBGから携帯側に送り返すべき結果が来ない状態でした。
つまり、三人娘はすかすかで、BG側が過負荷でパンク。
ということで、BG=>三人娘の送出が詰まっていたわけではなく、
BG側の処理が詰まっている状態と。
0045マァヴ ◆jxAYUMI09s @マァヴ ★
垢版 |
04/07/02 18:14ID:???
>44
えーっと(^_^;)どういう状態だったかってのは結果なので、それはそれでいいんですが
問題は
>BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
>そういう仕様になってたのかって話です(^_^;)
これなんですよ。もし、そういう仕様になってなかったら、BGが重くなるのは当然だと思えるので(^_^;)
0046root ★
垢版 |
04/07/02 18:14ID:???
クラシックメニューのPHPでの処理は、それなりにコスト高いです。
これと純粋なディスクI/O処理を分離したいというのが、今模索している方向かなと。
0047root ★
垢版 |
04/07/02 18:16ID:???
>>45
リバースプロキシはpoundをとりあえずほぼデフォルトで使いました。
この場合どうなるのかな。
0048マァヴ ◆jxAYUMI09s @マァヴ ★
垢版 |
04/07/02 18:20ID:???
>47
そこを検証しないと、結果だけ見て動いても問題は解決に近づかないと思われ(^_^;)
携帯側の低速なネットワークに対してバッファするのがフロントエンド
データをキャッシュすることで、フロントエンドのI/Oの負荷を下げ
かつ2ch側の負荷を携帯システムから分離するのがバックエンド
という役割分担をしたいわけなんだけど
もし、フロントエンドがパケット単位で受け取り>送出(つまりストリーミングな処理)をしていたら
今までフロントエンドが単独で処理してたより、状況が悪くなりですよ。
1 フロント、バックに分けたことによるオーバーヘッド
2 フロント3台の処理を、バック1台にまとめたことによる負荷
3 ボトルネックとなったバックエンドからの低速なアクセスによる2ch全体の負荷
0050マァヴ ◆jxAYUMI09s @マァヴ ★
垢版 |
04/07/02 18:23ID:???
少なくともフロントエンドは、携帯に送出する速度に関わらず
バックエンドから一気にデータを受け取ってしまわないと
携帯への送出速度に同期してバックエンドからデータを受け取ってしまうと
バックエンドが破綻するのはあたりまえといえばあたりまえの結果かと思います(^_^;)
0052 ◆BFzK/mtqM2
垢版 |
04/07/02 18:24ID:WZectPEP
これから負荷が重くなる時間なので、バックエンドにクラシックメニューにして、
プロキシのチューニングをまずやってみるのが先決かな?
0053マァヴ ◆jxAYUMI09s @マァヴ ★
垢版 |
04/07/02 18:41ID:???
理想を言えば
バックエンドはデータのキャッシュ、差分取得、必要分の送出の3つだけを黙々とこなして
フロントエンドは、データ送出バッファとread.cgi(およびその付加機能)を担当できればいいんだけどね・・・・(^_^;)
バックエンドにユーザーインターフェースとかが入ってくるのは
負荷集中を生み出すだけだと思われ。
0054動け動けウゴウゴ2ちゃんねる
垢版 |
04/07/02 18:44ID:+nStDpLJ
>>50
だあね。そのやり方だと結局今までと変わらないし。
フロント⇔バック間の処理は携帯の速度と非同期で
動かないと成功しないでしょう。

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

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

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

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

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

携帯     フロント     バック
   (PORT閉)      (PORT閉)
0055root ★
垢版 |
04/07/02 18:47ID:???
>>53
そうですね。というか当初からそれしかないと思われ。
0056マァヴ ◆jxAYUMI09s @マァヴ ★
垢版 |
04/07/02 18:55ID:???
>55
ですよね(^_^;)
で、リバースプロキシはそういう動作をするものなんでしょうか?
↑実はどういうものか全然わかってなかったりする(^_^;)
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況