【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part2 大黒埠頭
前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/ >>94 FOXさん、
では、ちょっとやってみます。
・受付嬢変更点
1) dat、subjectのリクエスト先をBGへ(PROXY経由)
2) キャッシュの作成を停止
3) 2)より、ディレイは実質的に0secへ(ディレイ処理はBG側に任せることになります)
BGは現段階でproxyとして動作可能なのでしょうか?
もし動作可能であるなら、接続の為のport等の情報をメールして下さると幸いです。 >>rootさん とりあえず、キャッシュ生成しないバージョンを入れてみました。
ちょっと、バグがあるけど(^^;
現在、ディレイなしで直接各サーバからdatを読み込み、それを処理するようにしてみました。
PROXYはとりあえずなしです。 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は劇的に低くなったがレスポンスは相変わらずですね。。。。 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がこんなに低いんだろう。。。。
全部読み込んでいるので、レス数が大きいスレは開くのに時間かかるね。
やはり、BG側で必要な情報だけを渡すようにする必要がありますね。 そこは注目のところですね、
受付嬢 - BlackGoat 間の通信が十分にはやいなら
受付嬢は dat の全データを貰っても貰わなくても ok な気がします。
もしこの間の通信がおそいなら・・・ 別の手を考える必要があるのかな?
まずは、毎回dat全取得という方法に固定しておきましょう。
次は BlackGoat でのキャッシングでどう変わるか。。。
1) 受付嬢の負荷はほとんど変わらないか、若干改善か?
2) 2ちゃんねるのサーバたちの負荷は大幅に改善される。
3) BlackGoat が受付嬢三人娘はかるがるとこなし、
10人までだったら相手にできるかも? の感触をつかむ。
そうですね。
受け付け嬢へのデータ加工機能をBGに入れるとすればそれなりの負荷が発生しますよね。
単なるプロキシならほとんど負荷はかからないんじゃないかな? >>◆BFzK/mtqM2さん、
ちょと改造されたところを拝見したのですが、
getres の 86 と 99 行目で2回にわたって dat リクエストしているようです。
どうしましょう、私が改造しても良いのかな?
もし複数人で改造を行うなら、日時と変更箇所を簡単にコメントした方が良いですね… 直しちゃってくださーい。
rewindがうまく行かなかったんで(^^;
そうですね。これからは変更したらコメント入れましょう。 >>107
DoCoMoはbananaの10Mbps制限に引っかかってるみたいだけど、
auは帯域制限が効いて無くて、20Mbps程度でてるみたい
>フロント←→2ch鯖間通信
その辺の関係で、DoCoMoは窓口数と処理が掃ける速度により
事実上アクセス上限に当たってる状況なのではないかと推測したり。 使用帯域は、どっちも 1Mbps 以下かそれくらいのような、 おぅおぅ
たしかに。。。
これが BlckGoat を通すことによってなくなるはず
というのが検証できますね。
BlackGoat - 2ちゃんねる の間はキャッシングすることによって
いろいろと、、、 >PIE-外部の帯域
の表現はちと違うかな?
http://server.maido3.com/pie/
のサーバのグラフは
青 Switch -> Server の使用帯域
緑 Server -> Switch の使用帯域です
また Switch 以降はルータまでとルータから外部は十分に太いので
青 外 -> Server の使用帯域
緑 Server -> 外 の使用帯域と言いかえられます。
これからの作業として 「受付嬢 - BlackGoat 間を
インターネット(GrovalなIP,ネット)を使ってをやっているのを
内部LANを使ってやる」となっています。
もし 10M の制限がなかったら
(((( ;゚Д゚)))ガクガクブルブル もんでしたなぁ
>>112
>PIE-外部の帯域
という表現が乱暴だった事は承知しておりますm(__)m
今回の作戦の成果(キャッシュ効率)を示す指標の一つはBlackGoatの
「Local(受付嬢)帯域 / Global(2ch)帯域」比をどれだけ大きくできるか、
ですね。
これからの流れとしては
(1) BGのキャッシュシステムを構築→キャッシュ効率・負荷の評価
(2) 受付嬢のチューニング→負荷、処理能力の評価
(3) 受付嬢-BG間のdat取得方法の見直し (BGのLAN側100Mbpsが飽和)
(4) 大黒埠頭時代を見据え、BGの性能評価。増強が必要ならスペック検討。
といった辺りでしょうか。
(3),(4)まで進んで嬉しい悲鳴をあげる事が出来ますように…(-人-) 現時点の受付嬢の仕様
(1)キャッシュなし
(2)その都度、2chの各サーバからdat全取得(過去ログ等はキャッシュしている)
(3)Delayなし
(4)docomoは10Mbps帯域制限中、auは10Mbps帯域制限かかっていない、othersは不明
各受付嬢の現状
docomo LAは低いが、帯域制限されてレスポンス遅い
au 帯域制限されていないので、比較的レスポンスはよい。ただしLAは高め
others いつも通り余裕
昨日・本日とおやすみしておりました。
というわけで、まずは>>93-94 >>96に対応します。 >>96
とりあえず設定しました。(Apacheのmod_proxy+mod_disk_cache)
c-au, c-docomo, c-othersから、192.168.0.1:80をProxyにしてみてください。 お、ちょっとまってください。
キャッシュ関連を調整します。>>116 携帯用と高機能版があるけど携帯用を選択したら見違えるくらい軽くなった。
高機能版はレスポンスに30秒以上かかっていたのに5秒くらいになった。 Bad Requestがでるな。。。
まだ設定終わっていないのか、送り方間違っているのかな。。。。 キャッシュの調整、おわりました。
ということで >>116 でおながいします。 >>120
Proxy経由で接続も確認できました。
これから三人娘に導入します。 HTTP/1.1 をつけてもいいのかな。
ちと、ためしてみるです。 c-othersからきはじめたかな。
>>126
どうもとらないとだめみたいですね。
設定をへまっているのかしら。(とりあえずApacheのmod_proxyを使用) 私のプロキシ側の設定がいまいちな予感。
ちと、とめてくださいです。 現在、c-othersで実験中
私のPCからのみPROXY接続で、それ以外は直接接続です。 Apacheのmod_disk_cacheにはバグがいるみたい。
.htmlな拡張子だとちゃんと動くけど、.datという拡張子だと
キャッシュにデータが入っている時に再度同じものをとろうとすると、
httpdがsignal 11で死んでしまう。
キャッシュしないモードではちゃんと動きますが、それじゃ意味ないし。
ということで、squidに切り替えます。 落着いて待ってます…
=≡= ∧_∧
/ (・∀・ )
〆 ┌ | | .∈≡∋
|| γ ⌒ヽヽコノ ||
|| .| |:::|∪〓 ||
./|\人 _.ノノ _||_. /|\ ―――――――――――――‐┬┘ =≡=
| __ 〆
____.____ | ─── \
| | ∧_∧ | | がっ! \_ =二 ∧_∧
| |. (#´Д`)| | _ |ヽ \ (; ・∀・)/
| |⌒ て) 人 _ ―――‐ γ ⌒ヽヽ ⊂ つ ∈≡∋
| |( ___三ワ < > ――― ―― ―二 | |:::| 三ノ ノ ノ ≡ //
| | ) ) | ∨  ̄ ̄ ̄ ―――‐ 人 _ノノ (_ノ、_ノ _//
 ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄ | おそくなりました。
192.168.0.1:8080
でやってみてください。HTTP/1.1 形式が必須のようです。 アクセスできました。
statusが返ってこないのがちょっと気になるが。。。。。
これでいってみますか。 >>135
アクセス確認しました。
statusは、、、設定しないとだめなのかな。
# なにぶん数年ぶりで設定するので。< squid othersを切り替えました。
statusは出来れば設定してほしいですね。
何か問題あるかもしれないけど、他も切り替えてみます diskdだとsquidが死ぬみたいなので、aufsに変更してみた。 >>142 の影響だとおもう。今はどうですかね。>>141 ということは
others au docomo の転送量が裏の経路に回るので
帯域問題は解決するかも? ということですね、
帯域問題が次に発生するとしたら BlackGoat - 各サーバの部分と、
期待したいのは「受付嬢は何も問題なく動きはじめる」といことだー。 aufsにした後は死ななくなったみたい。
status設定をちょっと調べてみます。 >>142
大丈夫になりました。
んじゃ、最後にdocomoも切り替えます。 おおっ 素晴らしい。。。
んで BlackGoat さんはdat,txtをキャッシュするですか? 時間帯があれなのでなんともいえませんが、いまのところゆとりあります。< blackgoat
>>144
そのように期待しています。 >>148
今のところなんでものはず。htmlでもgifでも。
Pragma: no-cacheとか命令されない限り。 ストライピングの効果がうまく出ているようです。
ディスクI/Oが2本のディスクに分散されて、いいかんじ。 いまのところ、datのみをリクエストしています。
あとで、subject.txtもPROXY経由で取得するように変更します。 >>149-150
りょうかいでーす
うまく動いているようなどっかで固定して
48h 間くらいいろいろデータ見てみたいでーす ごめん。今、1分ぐらいsquidとめました。
今日一時的に止める時は、ここに書きます。 お忙しい所すみませんガ
BlackGoat のキャッシュする機能としては
どかん設定なのでしょうか?
1) 何秒のディレイと考えればいいのか
2) BlackGoat - 2ちゃんねるのサーバ間の通信での差分読み込みの有無
3) BlackGoat に性能の限界が来るとすれば、どの部分と予想されるか、
この辺を記録として残したい気分です、 ログを見る限り、結構キャッシュはヒットしている予感。 とっても良さげなんだけど。。。
http://ch2.ath.cx/load/c-docomo.html
docomo だけ負荷が高いのはなぜなんだろう。
DISK i/o が無くなり、帯域の制限もなくなり・・・
何がネック? ディスクI/Oがなくなったので、
httpdでかけていた接続制限(128個まで)を大きくしてみることにした。< c-docomo
とりあえず128 => 192に変更。 うーん、体感的に c-docomo 早くなった希ガスる Apache statusで見る限り、さっきよりは健康になった予感(単に時間が遅くなったからかも)
既に現時点でF/Eのc-docomoは2台必要なのかも。 ちなみに三台とも同じ設定ですか?
違う場合は同じ設定にしていただけるとありがたいです
条件一定にしないと比較できないからでーす いずれにしても、今日一日様子見てみないとなんともいえませんね。 >>164
了解です。
これから3人娘の設定を>>161に変えます。 >>163
c-others がスカスカなのがもったいないよね。
必要なデータが取れた時点で、
banana405 上に c-docomo2 を作って、ラウンドプロキシで負荷分散ってのは?
>>166 done.
今の3人娘のhttpd.confの該当箇所:
<IfModule prefork.c>
StartServers 64
MinSpareServers 5
MaxSpareServers 32
ServerLimit 192
MaxClients 192
MaxRequestsPerChild 1000
MaxMemFree 2048
</IfModule>
php.iniでPHP accesralatorを導入。
zend_extension=/usr/local/lib/php/php_accelerator_1.3.3r2.so で、>>157 ですが、
1)F/E側の設定によります。
もしF/E側でディレイなしなら、ディレイなしです。
2)これもF/E側で制御できるのかな。
HTTP/1.1で制御すれば、それでいいはずなので。
3)しばらく見てみないとわからないですが、
ディスクI/Oかなとは思っていたり。 >>167
いやー まだまだ
r.i p.i とまってるのまだ 1/3 位だと思う(台数で)
今やりたい事は、「手法」の考案で劇的な変化を求めたいのだ
小手先の節約は劇的にはならないから
知恵をフル動因かと、
たぶん docomo の中の人とか au の中の人が通った道のりと思われるので
そこに少しでも近づければ、、、
きっと ニヤニヤされていると思われ、 >>169
なるほど、
で、F/E側の設定値はいかほどなんでしょうか? 3人娘の仕様は>>114です。
データを毎回読みにいくので必然的にディレイはありません。
また差分も内部にキャッシュ持たないため難しいでしょうね。 >>172
つまり、バックエンド側でディレイや差分を実装する(or しているソフトを入れる)
必要があるということですね。 うーん
ヒンフューズドというかコンプリケイティドというか
I am stupid 状態ですが
BlackGoat 側ではキャッシュの設定は受付嬢側に委ねられている設定で
受付嬢はキャッシュはしない設定であると。。。
ということは、どういうことなんでしょうか?
現在 BlackGoat はキャッシングしてない? バックエンドは、datが更新されれば内部キャッシュを更新しているんじゃないかな?
だからスレの速度がゆっくりしたデータは今以上にディレイ付くが、スレの速度が速い奴は頻繁に更新されるんじゃないかな? >>174
BlackGoatは現在、単純なProxyサーバとして動いています。
1)c-xxx →datのリクエスト→ blackgoat
2)blackgoatでdatの準備、こんなかんじ
if (blackgoatがそのdatを持っている) {
blackgoat →datの更新チェック→ 各サーバ
if (datが更新されている) {
// ここでsquidが増分取得をしているかは未確認
blackgoat →datのリクエスト→ 各サーバ
blackgoatはdatをキャッシュに格納
} else {
// キャッシュヒットにつきdatの取得はしない
} else {
// 持っていないのでdatを取得
blackgoat →datのリクエスト→ 各サーバ
blackgoatはdatをキャッシュに格納
}
3)blackgoat →datの送信→ c-xxx なるほど、なるほど
48h ほど観察して、次の話題は
1) BlackGoat にディレイ機能を入れたらどうなるか
→ 転送量(2ちゃんねる各サーバの負荷)
2) 差分読み込みまでする必要があるかどうかの検討
------------------------------------------
3) 受付嬢(とくに docomo) の負荷が高いのは
単純にアクセス数が多いからなのかどうか
あたりですかねぇ そうですね。そんなところかと。>>177
で、思いついたことを。
三人娘側でディレイを実現するのは、
どの板のどのdatをいつ最終取得したかをチェックできればいいわけです。
つまり、今までdat本体をストアしていたところに
大きさ0のxxxxxxxxxx.datファイルを作ることにして、
取得の際にそのファイルのmtimeを更新するようにするようにしておいて、
その時刻が現在時刻よりも120秒以上経過していなかったら、
blackgoat側にリクエストをそもそも発行しないようにする、というのはどうかなと。 >>178
これやると、ちょっぴりですが三人娘側でI/Oが発生しますね。
一番いいのは、blackgoat側で今もっているデータよりも120秒以上未来になってなかったら、
更新されていないとみなすようにすることか。
これってsquidの設定でできるのかしら。 >>178-179
これまでの雰囲気からは、 >>179 が本線だと思いますー つまり
現在の目標は、
1) 受付嬢の負荷を極力避けて、より多くのアクセスをこなせる様にする。
越えられない壁
2) 転送量等の話し、
ですから >>179
よくわからないけど、refresh_patternかな。 寝る前にごそごそ調べたら、squidはそもそもこの機能を持っているかも。
ということで、squid.confの設定を変えてみた。
なんとなくうまく動いているような予感。
# changed, 2 minutes delay
#refresh_pattern . 0 20% 4320
refresh_pattern . 2 20% 4320
それでは、おやすみなさい。 >>182
お、かぶりましたね。どうもそうみたい。 >root★さん FOX★さん
お疲れ様です。
昼時がどれくらいになるか楽しみですね。 ひるどき。-docomo, c-auとも劇重。
vmstat 1 で runnable process が150とか出るし。
PHPってこれ以上高速化できないのかしら。 c-others、blackgoatはまだ相当ゆとりありの模様。
あと念のため、裏側のネットワークの使われ具合をチェックしてみる必要があるかな。 どうだろう。PHPで毎回ページ作っている(= キャッシュされない)んじゃなかったっけ。>>190
で、産児制限するとそれなりにつながるようになるので、
接続要求を同時に受け付けすぎの予感も。< c-docomo ということで、観察を継続するために元の設定に戻しました。
重くても、明日夜まではこのままいきます。> c-{au,docomo,others} 今c-xxでは、リクエストした全てのdatが、まるまる配列に格納されています。
メモリに乗り切れてないってことはありますか? >>193
Perlでいう「連想配列がばちょ」ですね。
重そうな処理だなぁ。 c-docomo の負荷がなぜ高いかの推測大会ですね、
■ このスレッドは過去ログ倉庫に格納されています