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

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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

**動け動けウゴウゴ２ちゃんねる** · 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

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

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

>>100
よーわからんけど乙です。

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

全部読み込んでいるので、レス数が大きいスレは開くのに時間かかるね。
やはり、BG側で必要な情報だけを渡すようにする必要がありますね。

**FOX ★** · 04/07/04 04:38

そこは注目のところですね、

受付嬢 - BlackGoat 間の通信が十分にはやいなら
受付嬢は dat の全データを貰っても貰わなくても ok な気がします。
もしこの間の通信がおそいなら・・・　別の手を考える必要があるのかな?

まずは、毎回dat全取得という方法に固定しておきましょう。
次は BlackGoat でのキャッシングでどう変わるか。。。

1) 受付嬢の負荷はほとんど変わらないか、若干改善か?
2) ２ちゃんねるのサーバたちの負荷は大幅に改善される。
3) BlackGoat が受付嬢三人娘はかるがるとこなし、
　　10人までだったら相手にできるかも? の感触をつかむ。

◆BFzK/mtqM2 · 04/07/04 04:51

そうですね。
受け付け嬢へのデータ加工機能をBGに入れるとすればそれなりの負荷が発生しますよね。
単なるプロキシならほとんど負荷はかからないんじゃないかな？

◆EA.clAssIc · 04/07/04 10:26

>>◆BFzK/mtqM2さん、
ちょと改造されたところを拝見したのですが、
getres の 86 と 99 行目で2回にわたって dat ﾘｸｴｽﾄしているようです。
どうしましょう、私が改造しても良いのかな?
もし複数人で改造を行うなら、日時と変更箇所を簡単にｺﾒﾝﾄした方が良いですね…

◆BFzK/mtqM2 · 04/07/04 13:03

直しちゃってくださーい。
rewindがうまく行かなかったんで(^^;

そうですね。これからは変更したらコメント入れましょう。

◆BFzK/mtqM2 · 04/07/04 13:36

うーん、docomoはずーっと、アクセス数が一定なんだけど、、、
なんかしちゃったかな？
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-docomoaccess.html
その割にLAはずーっと一桁
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/c-docomoload.html

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

>>107
DoCoMoはbananaの10Mbps制限に引っかかってるみたいだけど、
auは帯域制限が効いて無くて、20Mbps程度でてるみたい
　＞フロント←→2ch鯖間通信

その辺の関係で、DoCoMoは窓口数と処理が掃ける速度により
事実上アクセス上限に当たってる状況なのではないかと推測したり。

**FOX ★** · 04/07/04 14:13

使用帯域は、どっちも 1Mbps 以下かそれくらいのような、

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

>>109
どもー。
1Mbps以下ってのはPIE-外部の帯域じゃないですか？

>>108で書いたのは
http://server.maido3.com/pie/graph/c-do.gif
http://server.maido3.com/pie/graph/c-au.gif
このグラフで言うところの青線の方です。

ここの傾向がauとDoCoMoで明らかに違うので何らかの
影響があるのではないかと思うのですが。
# いちおうリンク http://server.maido3.com/pie/

**FOX ★** · 04/07/04 14:42

おぅおぅ

たしかに。。。

これが BlckGoat を通すことによってなくなるはず
というのが検証できますね。

BlackGoat - ２ちゃんねる　の間はキャッシングすることによって
いろいろと、、、

**FOX ★** · 04/07/04 14:49

>PIE-外部の帯域

の表現はちと違うかな?

http://server.maido3.com/pie/
のサーバのグラフは
青 Switch -> Server の使用帯域
緑 Server -> Switch の使用帯域です

また Switch 以降はルータまでとルータから外部は十分に太いので

青外 -> Server の使用帯域
緑 Server -> 外の使用帯域と言いかえられます。

これからの作業として　「受付嬢 - BlackGoat 間を
インターネット(GrovalなIP,ネット)を使ってをやっているのを
内部LANを使ってやる」となっています。

もし　10M の制限がなかったら
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ　もんでしたなぁ

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

>>112
>PIE-外部の帯域
という表現が乱暴だった事は承知しておりますm(__)m

今回の作戦の成果(キャッシュ効率)を示す指標の一つはBlackGoatの
「Local(受付嬢)帯域 / Global(2ch)帯域」比をどれだけ大きくできるか、
ですね。

これからの流れとしては
(1) BGのキャッシュシステムを構築→キャッシュ効率・負荷の評価
(2) 受付嬢のチューニング→負荷、処理能力の評価
(3) 受付嬢-BG間のdat取得方法の見直し (BGのLAN側100Mbpsが飽和)
(4) 大黒埠頭時代を見据え、BGの性能評価。増強が必要ならスペック検討。
といった辺りでしょうか。
(3),(4)まで進んで嬉しい悲鳴をあげる事が出来ますように…(-人-)

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

現時点の受付嬢の仕様

（１）キャッシュなし
（２）その都度、２ｃｈの各サーバからdat全取得（過去ログ等はキャッシュしている）
（３）Delayなし
（４）docomoは10Mbps帯域制限中、auは10Mbps帯域制限かかっていない、othersは不明

各受付嬢の現状

docomo　LAは低いが、帯域制限されてレスポンス遅い
au 帯域制限されていないので、比較的レスポンスはよい。ただしLAは高め
others　いつも通り余裕

**root ★** · 04/07/04 21:50

昨日・本日とおやすみしておりました。

というわけで、まずは>>93-94 >>96に対応します。

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

>>96
とりあえず設定しました。(Apacheのmod_proxy+mod_disk_cache)

c-au, c-docomo, c-othersから、192.168.0.1:80をProxyにしてみてください。

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

お、ちょっとまってください。
キャッシュ関連を調整します。>>116

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

携帯用と高機能版があるけど携帯用を選択したら見違えるくらい軽くなった。
高機能版はﾚｽﾎﾟﾝｽに30秒以上かかっていたのに5秒くらいになった。

◆BFzK/mtqM2 · 04/07/05 00:28

Bad Requestがでるな。。。
まだ設定終わっていないのか、送り方間違っているのかな。。。。

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

キャッシュの調整、おわりました。
ということで >>116 でおながいします。

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

>>119
送り方ですが、>>93 の

GET http://qb5.2ch.net/operate/dat/1086680380.dat HTTP/1.1

は、

GET http://qb5.2ch.net/operate/dat/1086680380.dat

で、いいはず。

◆BFzK/mtqM2 · 04/07/05 00:46

>>120
Proxy経由で接続も確認できました。
これから三人娘に導入します。

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

HTTP/1.1 をつけてもいいのかな。
ちと、ためしてみるです。

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

>>122
ほい、ではよろしくです。

**FOX ★** · 04/07/05 00:48

わくわく

◆BFzK/mtqM2 · 04/07/05 00:52

？？
http1.1はとった方がいいのかな？

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

c-othersからきはじめたかな。

>>126
どうもとらないとだめみたいですね。
設定をへまっているのかしら。(とりあえずApacheのmod_proxyを使用)

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

私のプロキシ側の設定がいまいちな予感。
ちと、とめてくださいです。

◆BFzK/mtqM2 · 04/07/05 01:05

現在、c-othersで実験中
私のPCからのみPROXY接続で、それ以外は直接接続です。

**root ★** · 04/07/05 01:28

Apacheのmod_disk_cacheにはバグがいるみたい。

.htmlな拡張子だとちゃんと動くけど、.datという拡張子だと
キャッシュにデータが入っている時に再度同じものをとろうとすると、
httpdがsignal 11で死んでしまう。

キャッシュしないモードではちゃんと動きますが、それじゃ意味ないし。
ということで、squidに切り替えます。

◆BFzK/mtqM2 · 04/07/05 01:31

ﾏﾀｰﾘ待っています

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

　　　　　　　　　　　　　　　　　　落着いて待ってます…

　　　　　　　　　＝≡＝　∧＿∧
　　　　　　　　　／　　　（・∀・　）
　　　　　　　　〆　 ┌　 |　　　　| .∈≡∋
　　　　　　　　　|| 　γ ⌒ヽヽコノ　　 ||
　　　　　　　　　||　.｜　　　|:::|∪〓　 ||
　　　　　　　 .／|＼人＿.ノノ _||_.　／|＼

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

―――――――――――――‐┬┘　　　　　　　　　　　　　　＝≡＝
　　　　　　　　　　　　　　　　　 |　　　　　　　　　　　　＿＿　〆
　　　　＿＿＿＿.＿＿＿＿　　 | 　　　　　　　　　　　 ───　　＼
　　　　　|　　　　 |　∧＿∧ |　　 | がっ！　　　　　　　　　　　　　　　＼＿＝二 ∧＿∧
　　　　　|　　　　 |. （#´Д｀）| 　　|　　　　　　　　　　　　　　　　　＿　　|ヽ　　＼（；･∀･）／
　　　　　|　　　　 |⌒ 　　て)　　人　　　　　　　　＿　　―――‐　γ ⌒ヽヽ　⊂　　　つ　 ∈≡∋
　　　　　|　　　　 |（　　___三ﾜ＜　＞　　―――　　 ―― ―二　 |　　　|:::| 三ﾉ　ﾉ　ﾉ　 ≡ //
　　　　　|　　　　 |　)　　）　 | 　　∨ 　　　￣￣￣　―――‐　　人＿ノノ　（_ノ､_ノ　　＿//
　　　　￣￣￣￣'￣￣￣￣　　 |

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

おそくなりました。

192.168.0.1:8080

でやってみてください。HTTP/1.1 形式が必須のようです。

◆BFzK/mtqM2 · 04/07/05 02:49

アクセスできました。

statusが返ってこないのがちょっと気になるが。。。。。

これでいってみますか。

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

>>135
アクセス確認しました。
statusは、、、設定しないとだめなのかな。

# なにぶん数年ぶりで設定するので。< squid

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

たくさんきはじめました。

◆BFzK/mtqM2 · 04/07/05 02:52

othersを切り替えました。

statusは出来れば設定してほしいですね。
何か問題あるかもしれないけど、他も切り替えてみます

**FOX ★** · 04/07/05 02:53

今　others だけですか?

◆BFzK/mtqM2 · 04/07/05 02:53

auも今切り替えました。

◆BFzK/mtqM2 · 04/07/05 02:55

あら、スレありませんがでた。

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

diskdだとsquidが死ぬみたいなので、aufsに変更してみた。

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

>>142 の影響だとおもう。今はどうですかね。>>141

**FOX ★** · 04/07/05 02:56

ということは
others au docomo の転送量が裏の経路に回るので
帯域問題は解決するかも? ということですね、
帯域問題が次に発生するとしたら BlackGoat - 各サーバの部分と、

期待したいのは「受付嬢は何も問題なく動きはじめる」といことだー。

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

aufsにした後は死ななくなったみたい。
status設定をちょっと調べてみます。

◆BFzK/mtqM2 · 04/07/05 02:58

>>142
大丈夫になりました。

んじゃ、最後にdocomoも切り替えます。

◆BFzK/mtqM2 · 04/07/05 03:00

現在、３人娘はすべてPROXY経由になりました。

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

おおっ　素晴らしい。。。

んで　BlackGoat さんはdat,txtをキャッシュするですか?

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

時間帯があれなのでなんともいえませんが、いまのところゆとりあります。< blackgoat

>>144
そのように期待しています。

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

>>148
今のところなんでものはず。htmlでもgifでも。
Pragma: no-cacheとか命令されない限り。

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

ストライピングの効果がうまく出ているようです。
ディスクI/Oが2本のディスクに分散されて、いいかんじ。

◆BFzK/mtqM2 · 04/07/05 03:04

いまのところ、datのみをリクエストしています。
あとで、subject.txtもPROXY経由で取得するように変更します。

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

>>149-150
りょうかいでーす

うまく動いているようなどっかで固定して
48h 間くらいいろいろデータ見てみたいでーす

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

ごめん。今、1分ぐらいsquidとめました。

今日一時的に止める時は、ここに書きます。

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

>>153
そうですね。了解。

◆BFzK/mtqM2 · 04/07/05 03:12

いい感じですね。
http://server.maido3.com/pie/graph/blackgoat.gif

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

お忙しい所すみませんガ

BlackGoat のキャッシュする機能としては
どかん設定なのでしょうか?
1) 何秒のディレイと考えればいいのか
2) BlackGoat - ２ちゃんねるのサーバ間の通信での差分読み込みの有無
3) BlackGoat に性能の限界が来るとすれば、どの部分と予想されるか、

この辺を記録として残したい気分です、

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

ログを見る限り、結構キャッシュはヒットしている予感。

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

とっても良さげなんだけど。。。

http://ch2.ath.cx/load/c-docomo.html
docomo だけ負荷が高いのはなぜなんだろう。
DISK i/o が無くなり、帯域の制限もなくなり・・・
何がネック?

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

>>159
みてきます。

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

ディスクI/Oがなくなったので、
httpdでかけていた接続制限(128個まで)を大きくしてみることにした。< c-docomo

とりあえず128 => 192に変更。

◆BFzK/mtqM2 · 04/07/05 03:45

うーん、体感的に c-docomo 早くなった希ガスる

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

Apache statusで見る限り、さっきよりは健康になった予感(単に時間が遅くなったからかも)
既に現時点でF/Eのc-docomoは2台必要なのかも。

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

ちなみに三台とも同じ設定ですか?
違う場合は同じ設定にしていただけるとありがたいです
条件一定にしないと比較できないからでーす

◆BFzK/mtqM2 · 04/07/05 03:47

いずれにしても、今日一日様子見てみないとなんともいえませんね。

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

>>164
了解です。
これから3人娘の設定を>>161に変えます。

◆BFzK/mtqM2 · 04/07/05 03:54

>>163
c-others がスカスカなのがもったいないよね。

必要なデータが取れた時点で、
banana405 上に c-docomo2 を作って、ラウンドプロキシで負荷分散ってのは？

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

>>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

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

で、>>157 ですが、

1)F/E側の設定によります。
もしF/E側でディレイなしなら、ディレイなしです。

2)これもF/E側で制御できるのかな。
HTTP/1.1で制御すれば、それでいいはずなので。

3)しばらく見てみないとわからないですが、
ディスクI/Oかなとは思っていたり。

**FOX ★** · 04/07/05 04:01

>>167
いやー　まだまだ
r.i p.i とまってるのまだ 1/3 位だと思う(台数で)
今やりたい事は、「手法」の考案で劇的な変化を求めたいのだ
小手先の節約は劇的にはならないから

知恵をフル動因かと、

たぶん docomo の中の人とか au の中の人が通った道のりと思われるので
そこに少しでも近づければ、、、
きっと　ﾆﾔﾆﾔされていると思われ、

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

>>169

なるほど、

で、F/E側の設定値はいかほどなんでしょうか?

◆BFzK/mtqM2 · 04/07/05 04:16

３人娘の仕様は>>114です。
データを毎回読みにいくので必然的にディレイはありません。
また差分も内部にキャッシュ持たないため難しいでしょうね。

**root ★** · 04/07/05 04:18

>>172
つまり、バックエンド側でディレイや差分を実装する(or しているソフトを入れる)
必要があるということですね。

**FOX ★** · 04/07/05 04:21

うーん
ヒンフューズドというかコンプリケイティドというか
I am stupid 状態ですが

BlackGoat 側ではキャッシュの設定は受付嬢側に委ねられている設定で
受付嬢はキャッシュはしない設定であると。。。

ということは、どういうことなんでしょうか?

現在 BlackGoat はキャッシングしてない?

◆BFzK/mtqM2 · 04/07/05 04:28

バックエンドは、datが更新されれば内部キャッシュを更新しているんじゃないかな？
だからスレの速度がゆっくりしたデータは今以上にディレイ付くが、スレの速度が速い奴は頻繁に更新されるんじゃないかな？

**root ★** · 04/07/05 04:42

>>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

**FOX ★** · 04/07/05 05:01

なるほど、なるほど

48h ほど観察して、次の話題は
1) BlackGoat にディレイ機能を入れたらどうなるか
　→　転送量(２ちゃんねる各サーバの負荷)
2) 差分読み込みまでする必要があるかどうかの検討
------------------------------------------
3) 受付嬢(とくに docomo) の負荷が高いのは
　　単純にアクセス数が多いからなのかどうか

あたりですかねぇ

**root ★** · 04/07/05 05:51

そうですね。そんなところかと。>>177

で、思いついたことを。
三人娘側でディレイを実現するのは、
どの板のどのdatをいつ最終取得したかをチェックできればいいわけです。

つまり、今までdat本体をストアしていたところに
大きさ0のxxxxxxxxxx.datファイルを作ることにして、
取得の際にそのファイルのmtimeを更新するようにするようにしておいて、
その時刻が現在時刻よりも120秒以上経過していなかったら、
blackgoat側にリクエストをそもそも発行しないようにする、というのはどうかなと。

**root ★** · 04/07/05 05:56

>>178
これやると、ちょっぴりですが三人娘側でI/Oが発生しますね。

一番いいのは、blackgoat側で今もっているデータよりも120秒以上未来になってなかったら、
更新されていないとみなすようにすることか。

これってsquidの設定でできるのかしら。

**FOX ★** · 04/07/05 06:02

>>178-179
これまでの雰囲気からは、 >>179 が本線だと思いますー

**FOX ★** · 04/07/05 06:10

つまり
現在の目標は、
1) 受付嬢の負荷を極力避けて、より多くのアクセスをこなせる様にする。

越えられない壁

2)　転送量等の話し、

ですから

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

>>179
よくわからないけど、refresh_patternかな。

**root ★** · 04/07/05 06:29

寝る前にごそごそ調べたら、squidはそもそもこの機能を持っているかも。

ということで、squid.confの設定を変えてみた。
なんとなくうまく動いているような予感。

# changed, 2 minutes delay
#refresh_pattern . 0 20% 4320
refresh_pattern . 2 20% 4320

それでは、おやすみなさい。

**root ★** · 04/07/05 06:30

>>182
お、かぶりましたね。どうもそうみたい。

**root ★** · 04/07/05 06:32

ログ的に TCP_HIT がぐんと増えたから、うまくいっているのかな。

参考:
http://www.unix-power.jp/linux/redhat/squid1.html

◆BFzK/mtqM2 · 04/07/05 09:39

＞root★さん　FOX★さん
お疲れ様です。
昼時がどれくらいになるか楽しみですね。