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

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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

**げろっぴ** ◆/lQMO72QVo · 04/07/01 13:56

ヽ(･∀･)ﾉｳﾝｺｰ!!

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

２なら２ちゃん閉鎖

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

●はＰＣと共通で構わないのでは？
携帯上で購入可にするのは難しいのでしょうかねやはり

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

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

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

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

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

http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/597
597 ：だいこん ★ ：04/07/01 15:36 ID:???
毎日五個くらい携帯規制リストに追加している気がする。。。
リストが大きくなると、bbs.cgi が遅くなるというか負荷が上がるというか
処理が重くなるというか、、、

**root ★** · 04/07/01 23:55

>>9
携帯用判定文字列ってどんなかんじなんでしたっけ。
DNSにうまく載せられるのかしら。

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

私はパソコンがないので携帯から２ちゃんを閲覧しています。
携帯から閲覧できる機能は、とてもありがたいのですが、
そのせいで２ちゃんねるに負担をかけたり、以前のような閉鎖危機に陥ったりするのは嫌です。
サーバーの負担になるのであれば、携帯からの閲覧機能は無くてもいいです。
悲しいけど、２ちゃんねるが無くなるのはもっと悲しい。

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

>>11
俺はPCオンリーのユーザーだが君みたいな人にはなんとかしてあげたい

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

寄付とか受け付けてみたらどうでしょ？

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

>>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の "_" 以外は大丈夫そうですねー

◆BFzK/mtqM2 · 04/07/02 10:08

規制するのは端末固有情報だから、bbs.cgi叩きにいくときしか出さないはず。

**root ★** · 04/07/02 10:33

そうだ。せっかく占有のスイッチでつながってるんだから、
datディレクトリをNFSするというのはどうだろ。

あとで、やってみよう。

**未承諾広告※** ◆TWARamEjuA · 04/07/02 11:01

use Digest::md5;
:
:

sub Get_Mobile_ID($) {
my $Mobile_ID = Digest::md5->new;
$Mobile_ID->add(shift);
return $Mobile_ID->base64digest;
}
:
:

DispError('ＥＲＲＯＲ！', '寄生虫')
　if join( '.', unpack 'C4', sprintf qq|%s.bbm.2ch.net|, Get_Mobile_ID($ENV{HTTP_USER_AGENT})) =~ /^127.0.0/ ;

UA をそのまま MD5 にして bbm（仮名）送りはちょと強引かな？(^-^;)

◆BFzK/mtqM2 · 04/07/02 12:11

確かにNFSにするのが一番簡単ですね。
それならばクラシック側は変更もいらないですね。

**root ★** · 04/07/02 12:17

>>16
datの下だけNFSにすると「キャッシュが作成できません」と言われるなぁ。
たぶん、何か呪文が必要なのかも。
これ以上は中の人に聞かないと。

**root ★** · 04/07/02 12:17

>>18
単に、datの下をNFSに(動かしながら)するんじゃだめなんでしたっけ。
何か設定が必要なんだっけか。

**root ★** · 04/07/02 12:19

うーむ、NFSじゃなければいきなりmvしてもいけるみたい。
だとすると私の設定の問題か。

**root ★** · 04/07/02 12:24

>>21 は勘違いでした。どうもいきなりmvするんじゃだめかも。
結局 >>19 か。

◆BFzK/mtqM2 · 04/07/02 12:29

パーミッションはどうなっていますか？
777ならキャッシュ作れると思うんだけどな～

**FOX ★** · 04/07/02 12:31

出来れば「目的」を書いてから「手段」(たとえば >>21)を書いていただけると
とてもありがたいです、

なにをしたいんだろう
そしてそれは何が目的なんだろう
結果どうなったんだろう

**FOX ★** · 04/07/02 12:49

マーリンルージュ作戦の目的をおさらいしよう。

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

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

つまり

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

大黒埠頭は
BBM等の各種一元管理＋四台目以降の増設方法(テクニカル、ポリティカル、エコノミカル)です

**root ★** · 04/07/02 13:00

>>24
今回の目的は、前スレにもありますが、

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

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

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

BBM(仮称)はBBQ同様、banana238かoyster243かな。
管理する必要があるデータの大きさで決まると思います。
小さければbanana238、大きければoyster243。

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

というわけで、目的 (>>25) の 3) と 4) を実現しようというのが、
今回の眼目になりますね。

5)は「重くても重いなりに動く」という、現在の路線(LA=100でも一応動きはする)
という方向で、チューニングをすることになるかと。

**FOX ★** · 04/07/02 13:08

現在行っていることは、以下の事だと思っています
right ?

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

現在ここ

5) c-docomo の負荷が劇的にさがる　←　期待されること(達成すべきこと)

**root ★** · 04/07/02 13:16

>>28
3)までは概ねcorrect.

現在4)の方法を模索している状態。

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

いまのc-othersのdatはNFS？

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

28-29
3.1)定期的に各鯖から差分ＤＬ
3.2)書き込み後もＤＬ

と妄想してみたり・・・

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

(^_^;)

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

昨夜やってみたことの簡単なまとめ:

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

その結果わかったこと

・対携帯のネットワーク処理だけを別マシンに移す方式ではだめだった

04/07/02 14:04

>>32
むむむさん、それって、失敗の巻きって事ですね。

04/07/02 14:10

うんこ

**root ★** · 04/07/02 14:24

>>32
うん。ということで >>26 なわけだ。

**root ★** · 04/07/02 15:14

NFSでうまくいかなかったのは、statd/lockdを上げていなかったからだとわかりました。
(NFS設定するのなんて昔のSun以来だから、すっかり忘れていた)

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

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

ということで、NFS路線はどうもやめたほうがいいみたい。
やっぱり、三人娘のクラシックをクラシック改にする必要がありそう。

◆BFzK/mtqM2 · 04/07/02 15:19

じゃあ週末にでもその辺の改造をやってみます。

**root ★** · 04/07/02 15:30

>>37
了解です。

では、blackgoatではProxyモードでApacheを上げておきます。
使い方等は別途。

◆BFzK/mtqM2 · 04/07/02 15:42

了解です。
キャッシュのdelayは黒山羊さんが握るんだよね。

**root ★** · 04/07/02 16:13

>>39
squidのdelay poolsを使えばいいかな。
Apacheのmod_proxyではできるんだっけ。

**root ★** · 04/07/02 16:18

>>40
あ、時間って指定できないかも。< squid

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

あらまほしい動作は、datが更新されていた場合でも
120秒は読み込まない、ということですよね。

◆BFzK/mtqM2 · 04/07/02 16:45

そうですね。
ちゃんとやるには差分とDelayを黒山羊さんに実装しないといけませんね。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 17:37

質問です(^_^;)
１　今回の失敗の巻は
　・BGにクラシックメニューを設置
　・受付嬢をリバースプロキシに変更
　だったのかな？

２　リバースプロキシはBGからのパケットをバッファして送出してたのかな？
　　つまり、BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
　　そういう仕様になってたのかって話です(^_^;)

**root ★** · 04/07/02 18:12

>>43
1 Yes. (私としては正直「予想通りの失敗」です)

2 なかなかBGから携帯側に送り返すべき結果が来ない状態でした。
つまり、三人娘はすかすかで、BG側が過負荷でパンク。
ということで、BG=>三人娘の送出が詰まっていたわけではなく、
BG側の処理が詰まっている状態と。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:14

>44
えーっと(^_^;)どういう状態だったかってのは結果なので、それはそれでいいんですが
問題は
＞BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
＞そういう仕様になってたのかって話です(^_^;)
これなんですよ。もし、そういう仕様になってなかったら、BGが重くなるのは当然だと思えるので(^_^;)

**root ★** · 04/07/02 18:14

クラシックメニューのPHPでの処理は、それなりにコスト高いです。
これと純粋なディスクI/O処理を分離したいというのが、今模索している方向かなと。

**root ★** · 04/07/02 18:16

>>45
リバースプロキシはpoundをとりあえずほぼデフォルトで使いました。
この場合どうなるのかな。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:20

>47
そこを検証しないと、結果だけ見て動いても問題は解決に近づかないと思われ(^_^;)
携帯側の低速なネットワークに対してバッファするのがフロントエンド
データをキャッシュすることで、フロントエンドのI/Oの負荷を下げ
かつ２ｃｈ側の負荷を携帯システムから分離するのがバックエンド
という役割分担をしたいわけなんだけど
もし、フロントエンドがパケット単位で受け取り＞送出（つまりストリーミングな処理）をしていたら
今までフロントエンドが単独で処理してたより、状況が悪くなりですよ。
１　フロント、バックに分けたことによるオーバーヘッド
２　フロント３台の処理を、バック１台にまとめたことによる負荷
３　ボトルネックとなったバックエンドからの低速なアクセスによる２ｃｈ全体の負荷

04/07/02 18:23

プロキシってのはそういうモンじゃないっしょ

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:23

少なくともフロントエンドは、携帯に送出する速度に関わらず
バックエンドから一気にデータを受け取ってしまわないと
携帯への送出速度に同期してバックエンドからデータを受け取ってしまうと
バックエンドが破綻するのはあたりまえといえばあたりまえの結果かと思います(^_^;)

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:24

>49
あ(^_^;)おいらの認識が間違ってるってのは普通のことです
なので「質問」なのですよ。

◆BFzK/mtqM2 · 04/07/02 18:24

これから負荷が重くなる時間なので、バックエンドにクラシックメニューにして、
プロキシのチューニングをまずやってみるのが先決かな？

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:41

理想を言えば
バックエンドはデータのキャッシュ、差分取得、必要分の送出の３つだけを黙々とこなして
フロントエンドは、データ送出バッファとread.cgi（およびその付加機能）を担当できればいいんだけどね・・・・(^_^;)
バックエンドにユーザーインターフェースとかが入ってくるのは
負荷集中を生み出すだけだと思われ。

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

>>50
だあね。そのやり方だと結局今までと変わらないし。
フロント⇔バック間の処理は携帯の速度と非同期で
動かないと成功しないでしょう。

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

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

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

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

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

携帯　　　　　フロント　　　　　バック
　　 (PORT閉) 　　　　 (PORT閉)

**root ★** · 04/07/02 18:47

>>53
そうですね。というか当初からそれしかないと思われ。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:55

>55
ですよね(^_^;)
で、リバースプロキシはそういう動作をするものなんでしょうか？
↑実はどういうものか全然わかってなかったりする(^_^;)

**▲ 某ソレ511** · 04/07/02 18:57

リバースプロキシの検索結果のうち日本語のページ約 1,900 件中 1 - 50 件目 (0.43 秒)

http://e-words.jp/w/E383AAE38390E383BCE382B9E38397E383ADE382ADE382B7.html

**root ★** · 04/07/02 18:57

>>54
昨日やったのはこれですね。★のところが重いわけです。

ちなみに現在の各フロントエンドので発生しているディスク書き込み量は、
ピーク時のgame6の倍以上、負荷がやや高い時のlive8ぐらいあります。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/io/

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

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

携帯　　－　　フロント　　←　　バック
　　 TIME_WAIT　　　　　★必要に応じdatを取得・datを保存・PHP処理・結果転送

携帯　　－　　フロント　　　　　バック
　　 TIMEWAIT そのまま転送　(PORT閉)

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

携帯　　　　　フロント　　　　　バック
　　 (PORT閉) 　　　　 (PORT閉)

**FOX ★** · 04/07/02 18:58

>>57
このスレッドに記録するのが目的だったり

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

>>56
そういう動作はしませんです。

今回の実験は、前スレのこれ↓を受けた試験だったということで。

960 名前： ◆BFzK/mtqM2 [sage] 投稿日：04/06/30 18:23 ID:vQ7rJwVR
クラシック本体をバックエンドに持ってきて、フロントを介して携帯とやりとりするのかな？

961 名前：root ★[sage] 投稿日：04/06/30 20:22 ID:???
>>960
はい、最初(Tigerサーバ/w SCSI stripeが入る前提だったころ)は、それも考えていました。
で、各フロントエンドは、リバースプロキシをすると。

しかし、今回入るバックエンドはbananaサーバです。
ということで、PHPをバックエンドではあんまり動かしたくないかもなぁと。

ただ、どっちの方式がいいかは、やってみないとわからないところがあります。

1)方式1

・フロントエンドはクラシック(改)
・バックエンドはApacheのプロキシ+キャッシュ

2)方式2

・フロントエンドはApacheのリバースプロキシ
・バックエンドはクラシック

962 名前： ◆BFzK/mtqM2 [sage] 投稿日：04/06/30 20:33 ID:vQ7rJwVR
まずは、負荷かかるかもしれないが、（2）を試して、
その間に（1）の準備をしましょうか。

963 名前：root ★[sage] 投稿日：04/06/30 20:47 ID:???
>>962
そうしますか。
なら、一番苦しいとこからやんないと意味ないですね。
c-auやc-othersは何とかなってるから、自動的にあれかぁ。

**▲ 某ソレ511** · 04/07/02 19:05

いやこのリンク先、単なるIT用語辞典なんだけどね、、
さすがに用語の意味くらいなら検索したほうがいいんじゃないかと思って。
IT用語辞典が消えることはインターネットがある限りないと思うし。
それをどのように適用するかなら書いても価値があると思うんですけど、、

とりあえずかいつまんで書いておくと、
　外部からネットワーク内部へのアクセスをする際に通されるもののことで、
　中継時にURLやパケットの内容を保存することでセキュリティを強化したり
　アクセス数の多いデータをキャッシュとして保存することにより高速化したりできる。（←今回はこれが目的かな）
　内部から外部へ接続するプロクシの反対なので「リバース」がつくと言われている。
こんなところかな、

**root ★** · 04/07/02 19:10

で、もしバックエンドのPHP処理やディスクI/Oがおなかいっぱいで、
かつクラシックメニューが簡単には改造できないとしたら、
以下の構成もありかなと。

フロント <=> バックエンド1(クラシック)
　　　　　<=> バックエンド2（クラシック)
　　　　　<=> バックエンド3(クラシック)

フロント<=>バック間はリバースプロキシでURLを見てロードバランスする。
(これは簡単に設定できます)

つまり、ディスクI/OやPHPをやる人の負担を単に1/3に薄めると。

**root ★** · 04/07/02 19:12

で、>>62 の構成は今の路線(今はURLを見るのではなくて、au/docomo/othersで割っている)
で、これを細かく割ると。

ただ、どうみてもこれは筋悪だし、本格的な解決になってないというのがここの判断かなと。
ということで、>>53 >>54 方式かなと。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 19:13

>62
それだと携帯ユーザーが満足できるだけバックエンドを入れた時点で２ｃｈ側の負荷が・・・・(^_^;)
フロントいっぱい＞バックエンド少し＞２ｃｈ
という分散モデルにならないと・・・・(^_^;)

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 19:14

まー、外野であれでなと、これでないとと騒ぐのは簡単なんですけどね(^_^;)

**root ★** · 04/07/02 19:16

>>64
ということで世間的には、バックエンド1,2,3を
別途用意した同じProxyサーバにつなぐわけです。はい。

**root ★** · 04/07/02 19:18

ただ今回は、もうめざす路線は概ね合意できている気がするので、

・携帯からの受付・PHP処理・dat/subject.txtリクエスト…フロントエンド
・フロントからのリクエスト受理・dat/subject.txt取得・管理…バックエンド

その形をめざして動くことでよいのではないかと。

**root ★** · 04/07/02 22:07

blackgoat、これからちょっとファイルシステムのチューニングをしてみます。

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

Pekoでやったようなメモリ周りのチューニングはいかがでしょ

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

blackgoat、チューニングできた。
ちょっと、c-docomoでためしてみます。

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

c-docomo => blackgoatを復活させた。
さて、どこまで上がるか。< blackgoat

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

今のところいい感じ？
ttp://mumumu.mu/mrtg/mrtg-rrd.cgi/load/c-docomoload.html

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

ccdを使って、blackgoatのディスクをストライピングにしてみた。
ちゃんとad0とad1にほぼ均等にアクセスがいくようになった模様。

ただし、ディスクは確かに楽になったけど、LAは改善されてないみたい。

ただ、今はまだ無制限に受け付けるので、
接続が目いっぱいまで使われてしまうことも、原因にあるかなと。

httpdを24, 32, 48, 64, 96, 128, 160 と変えて試してみたけど、
24の状態で既にPHP処理だけでCPUはめいっぱいみたい。
ほとんどのhttpdはRUN状態(PHP処理中)になっています。

で、マァヴさんが言っていた状態になっているかどうか(BlackGoat側の送信部分が
ふん詰まり状態になっているか)をnetstatコマンドなどで確認してみましたが、
いずれの状態もバック=>フロントへの送信そのものは速やかに終わっていました。

つまり、BlackGoat側からフロント側への送信はすばやく終わっていて、
BlackGoat側で送信そのものに詰まっている状態は、観測されていませんでした。

コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。
接続数を多くするとリニアにLAが上がっていく状態。
実はへたすると、PHPの処理の方がディスクI/O処理よりもコストが高いのかも。

自宅に帰ったらフロントエンド側を調整して、接続数制限を入れてみるか。

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

>>72
そっちは、ねぇ。PHP処理とディスクI/O処理をしない状態になるから、軽くなるんですよ。
こっちが、重要。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/blackgoatload.html

実際のDoCoMoのユーザさんのレスポンス具合はどうかなと。
たぶん、今は昨日までとあんまり変わらないはず。

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

>コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。

って、BlackGoat の話しですか?

であるならば、
まずは何よりも先に「本来の目論見である、DISK i/o だけ」にするのが先かと、

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

>>74
あんまり変わらないですね。ただもともと接続速度が遅いので
そんなに気になりませんが。
FOMAの人は気になるレベルかもしれません。