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

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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

**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★さん
お疲れ様です。
昼時がどれくらいになるか楽しみですね。

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

なかなか更新されませんね。

**root ★** · 04/07/05 12:26

ひるどき。-docomo, c-auとも劇重。
vmstat 1 で runnable process が150とか出るし。

PHPってこれ以上高速化できないのかしら。

**root ★** · 04/07/05 12:27

c-others、blackgoatはまだ相当ゆとりありの模様。
あと念のため、裏側のネットワークの使われ具合をチェックしてみる必要があるかな。

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

受付嬢の前にもプロキシを置くと緩和されないかな？

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

どうだろう。PHPで毎回ページ作っている(= キャッシュされない)んじゃなかったっけ。>>190

で、産児制限するとそれなりにつながるようになるので、
接続要求を同時に受け付けすぎの予感も。< c-docomo

**root ★** · 04/07/05 13:11

ということで、観察を継続するために元の設定に戻しました。
重くても、明日夜まではこのままいきます。> c-{au,docomo,others}

◆EA.clAssIc · 04/07/05 13:34

今c-xxでは、ﾘｸｴｽﾄした全てのdatが、まるまる配列に格納されています。
ﾒﾓﾘに乗り切れてないってことはありますか?

**root ★** · 04/07/05 13:59

>>193
Perlでいう「連想配列がばちょ」ですね。
重そうな処理だなぁ。

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

c-docomo の負荷がなぜ高いかの推測大会ですね、

04/07/05 15:21

よーしじゃんじゃん妄想するぞー

**root ★** · 04/07/05 15:22

>>195
ちなみに昼休みはc-auも高負荷だったので、
アクセス数が多いことは当然原因の一つではあるかなと。

わたし的には「単純に数が多くてもうむりぽ」なのか、まだ改善の余地はあるのか、
が問題で。

vmstatでみると、httpdがRUNになっている状態のものが圧倒的に多いですね。
つまり、処理がおいついていないように見える。

blackgoatは今のところ余裕があるので、横並びでc-docomoをもうひとつ増やしてみる
というのは、可能ではあるのかも。

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

資料

転送量(使用帯域　対インターネット)
http://server.maido3.com/pie/

http://server.maido3.com/pie/graph/c-au.gif
http://server.maido3.com/pie/graph/c-do.gif
http://server.maido3.com/pie/graph/c-ot.gif
http://server.maido3.com/pie/graph/blackgoat.gif

アクセス数
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/

http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-auaccess.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-docomoaccess.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-othersaccess.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/blackgoataccess.html

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

公衆便所の壁になに書いてもおんなじやで、ハヨみんな死ねよ、ちんぽおめこ、くさー

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

>>197
そういう事じゃなく

今まで
1) DISK i/o が問題と推測　→　DISK i/o をなくした
2) 帯域が問題と推測　→　帯域制限にかからないように方式変更
3) 今度は何?

前提としては「需要 > 供給」は当たり前なわけで、

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

>>200
なるほど。現有戦力で次にとれる手法は何で、そのための戦略は何？
ってことですか。

ちなみに、下記は済みのもの。

0) PHPの処理に時間がかかる → PHP acceralator導入(倍ぐらいのパフォーマンスに)

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

>>201
そです　そです。
そして突然「素晴らしい発想」が生まれ、「劇的な改善」が見込まれると、
1000% 効率アップとか、
それが出来るのは「若い柔軟な脳」だけかと、

**未承諾広告※** ◆TWARamEjuA · 04/07/05 15:56

・ 3 人娘を単なるクローンにする。
・ c.2ch.net はシリアル番号（機種固有番号）からランダムにいずれかの 3 人娘を呼び出す。
→ランダムなので純粋に負荷が 3 等分されるのではないか？＠帯域、負荷

○ 現状 3 人娘はそれぞれ違う処理を行っている？
→ HTML, HDML, MML, XML と違う出力にしているならば、
　その部分を切り離して UA でそれぞれ振分けてパイプ処理で変換させるとか？（nkf みたいな pod2html みたいな）

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

>>203
単に負荷を3等分する、というのは前にも少し考えました。
今でもpoundで簡単にできるけど。やってみますか？

後者は、中身の重そうな処理がどこかを調べることになるのかな。

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

c-docomo の挙動

http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-docomoaccess-day.png
これが c-docomo に襲い掛かっているアクセスである。
48hの推移を見ると三つの部分に分かれている
1) 最初の3kくらいのところ　→　DISK i/o が率速だった
2) 5k 位の平坦部　→　10Mbps の帯域制限が率速だった
3) 10k - 25k を乱高下　→　純粋に襲い掛かっているアクセス?

と考えていいんだろうか、実はどこかに別の秘密が隠されているのだろうか、
解せないのは、　3) が本来のアクセスならばなぜ 1) 2) が平坦になり乱高下が
観測されないんだろう。

>>204
だめだめ、ここからもしかしたら確信なのかも知れないから
台数増やすのはいつでも簡単に出来る一番安易な方法です
また、今の目標はそこにはないです。

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

>>204
c-docomo を軽くしようというのは目標ですが
絶対に他のキャリアとまぜないでください
勿論、au もですけど、

せっかく分けて、分析しているのですから、

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

簡単に言えば

「台数増やす　→　軽くなる」は既に解っている解決策ですから
実験する必要は全くないと思います。
平均化も台数増やすと同じことです。

**未承諾広告※** ◆TWARamEjuA · 04/07/05 16:19

>>205
> 3) 10k - 25k を乱高下　→　純粋に襲い掛かっているアクセス?
転送速度も絡んでいるのかもですね。
c-docomo 内部では処理が終わっているのに、なかなか全部受取ってくれていないとか。＠mova類

あと気になるのが鯖名。4xx 台ってば httpd のエラーコードなんですよねぇ(^-^)

**root ★** · 04/07/05 16:21

>>205-207
了解です。物量以外の知恵で。

ccdによるストライピングにしてもそういうことでひねり出したわけで、
(これでディスクI/Oのキャパが2倍近くになった)。

で、乱高下は「その時の限界ぎりぎりまで資源が使われた場合」にこうなるようです。

でも、限界だと思っていたのが実は限界ではなかった、ってのを
既に何度も経験しています。

というか、弱いマシンでやらないと、弱点も見えてこないものです。
強いマシンだと詰めが甘くても、動いてしまうし。

このへんの「苦しいマシン環境での力のしぼり出し」は本業的に昔取った杵柄なので、
(もう何年もやってないけど)もう少しがんがってみようかなと。

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

ロードアベレージで負荷を見ているわけですが、

LA 高の原因は単純に言って
入ってくる量 > 完了する量　なわけです。
つまり処理が完了する量に注目すれば(動かすことの出来る項だと仮定すると)
どんどん完了すればいいわけです。

なぜ完了しないのか?
c-docomo が完了できないのか
呼び出し側が完了してくれないのか。。。

**root ★** · 04/07/05 16:33

>>210
見ている限りでは、c-docomoが完了できないように見えますね。
常にhttpdがCPUを食っていて、とても多忙に見えます。

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

一つの呼び出しを処理するのにかかる平均時間というのは計測できるんですかねぇ
docomo の場合
au の場合
その他の場合

で知ることが出来たら、何か出てくるかも、

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

>>211

>c-docomoが完了できない

と原因を仮定すれば、どこが問題ななんだろうか?

1) CPU 性能?
2) RAM 不足?
3) network ? or その他?

何を見たらそう断定できる?
また解決すればどれくらいの効果が見込める?

逆に、ハードは変更しないとしたらどんな解決方法があるか?

◆Reffi/bQ.c · 04/07/05 17:16

あくまで仮説ですけど定額制端末に焦点を当てると違いは転送速度です
のでそれが処理の遅れになってるかもしれませんね

ＦＯＭＡ　　　最大３８４Ｋ
ＡＵ（ＷＩＮ）　最大２．４Ｍ

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/05 17:20

>214
非定額の場合でも大きな違いがありますよ(^_^;)
Docomoの主力の5xx&2xxシリーズは9600bpsだったはず。
auの主力の1xは144kbpsだったかな？
詳しい人フォローよろしく。

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

ちょっと疑問というか不思議なのは
当初、au : docomo : others = 4:5:1.5 という計測結果があって、
その上でいろいろ進めてきたわけですが、

http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/

を見ると　4:10:1.5 に見えます。
どしてこんなに docomo の比率増えたのだろぅ

うーむ疑問だらけじゃ

04/07/05 17:23

>>214
いくら携帯2chユーザのWIN率が高いって言ってもWINを基準にはできんじゃろう
FOMAも同じく
mova 最大 28.8kbps (505i以降)
au 最大 144kbps

04/07/05 17:23

ってマァヴの親父とかぶったよ

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/05 17:24

でも、よーわからんのだけど、ネットワーク速度がボトルネックなってる場合
１　コネクションが足りなくなって、エラーを返す
２　コネクションを開放できなくてメモリが不足してスワップが起こってLAが上がる
のどっちかになるんでないのかな？(^_^;)
現状、LAが高いんだから１ではないわけで・・・・

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/05 17:25

>217
あ、28800bpsまで上がってるのか(^_^;)＞5xx,2xx