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

**FOX ★** · 04/02/04 18:37

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

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

Love Affair 作戦。
Part1 マーリンルージュ

**root ★** · 04/06/25 17:35

苦しくなったら、やめる予定。>>719
バックエンドがないから、たぶん苦しくなるかなというのが予想。(特にc-docomo/c-au)

**root ★** · 04/06/25 17:50

今の様子は、

・c-docomo ほぼめいっぱい、データのはけが悪い、たぶん最初に音を上げそう
・c-au かなりきてる、でもデータがはけるのも早い、CDMAだから? それともキャッシュの効果?
・c-others 余裕あり

というかんじかなぁ。

**未承諾広告※** ◆TWARamEjuA · 04/06/25 17:56

ＥＲＲＯＲ：referer情報が変です。(ref1)http://c-others.2ch.net/z/-/1C/A9-3t/w

怒られました（苦笑）＠ PC からの書き込みです。

**動け動けウゴウゴ２ちゃんねる** · 04/06/25 17:58

そらそーだ。

◆BFzK/mtqM2 · 04/06/25 19:23

root★さん

c-docomo、c-otherもc-auと同じIPからのアクセスを許可してもらえますか？

◆/yjFd7fSrw · 04/06/25 20:43

>>721
そういえば、auはDocomoよりもパケット通信の速度が速かった気が
64～144Kbpsぐらいだったかな？
Docomoは新しいもので28.8Kbpsだそうで

**動け動けウゴウゴ２ちゃんねる** · 04/06/25 21:46

>725
auはWinが出来たので最大2.4Mbps
DoCoMoはFOMAが出来たので最大386Kbpsぢゃなかったっけ？

**動け動けウゴウゴ２ちゃんねる** · 04/06/25 21:52

Docomoの中間鯖が込んでるからハケがわるい
auの中間鯖は込んでないからハケがいい

**動け動けウゴウゴ２ちゃんねる** · 04/06/25 23:27

c-auのLAがｃ－DoCoMoに比べて一桁多いのですが・・・(汗汗
bananaでLA70越えって耐えられるのか・・・？
このままだと三桁いかないか？
まぁ、どっちにしろauの自業自得か・・・。

（このまま続くようだったら、KDDI.何チャラ．UPbrowser（新機種系）と
UPbrowser/何チャラ（旧機種+ツーカー系）と分けた方がいいかもね～　
　旧機種系+ツーカーならc-oﾃherに処理させても余裕なんじゃないかな？
　まぁ、au+Tu-kaを優遇する必要が無いから自業自得でもいいけど～♪）

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 00:56

c-auにせよ、c-Docomoにせよ、LA100を超えるってのは異常事態でしょう。
PCでUAを偽装してリロードをかけているお莫迦さんがいるのでは…

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

ログがあるのなら、IPでPC偽装と実機率を割り出してみたらどうだろうか？

**root ★** · 04/06/26 02:20

>>724
既にそうなっているはず。

**root ★** · 04/06/26 02:21

>>729
アクセスログをざっと見る限り、そうは見えないですね。
ほとんどが普通に携帯から来ていると思われ。

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

参考データ出てます。
http://hobby6.2ch.net/test/read.cgi/phs/1086459593/944
944 ：非通知さん：04/06/26 02:24 ID:z3m3bD0G
>>942
お、WIN版のスピードテスト開始してるね。

回線速度統計
(docomo)
◎過去50件の統計
・分布図
・最高 288kbps
・最低 43kbps
・平均 176.98kbps
　(23:21～02:14)

回線速度統計
(KDDI)
◎過去50件の統計
・分布図
・最高 393kbps
・最低 256kbps
・平均 322.88kbps
　(02:10～02:23)

04/06/26 10:04

>>729
そんな馬鹿はいないと思われ・・・

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 10:08

なんか参考になるかもしれないんで貼っておきます
http://qb5.2ch.net/test/read.cgi/operate/1086680380/665-673

そら ◆N2102V.3tM · 04/06/26 10:33

(ﾟДﾟ)ﾊｧ?

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 11:27

>>732
なるほど。
携帯からのアクセスが、いかにフロントエンドに負担をかけているかってことですか。

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 19:24

DoCoMo重いyo!!

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

そろそろ、ﾄﾞｺﾓに金出させる or ﾄﾞｺﾓ網からのｱｸｾｽ制限を
かけておく、とかしないと、ﾄﾞｺﾓﾕｰｻﾞｰが激増して２ちゃん
が破綻するぞ

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 20:22

そんな未来のことを語られても。。。

その時はその時、ですです。

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 20:37

「困ったときに考えよう」

　　　　　　　　　　　　　ぴろゆき

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 20:51

>>741 「考える、実際に働くのは他人」 by ひ(ry

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/26 22:12

>739
そのためのフロントエンドだと思うんだが(^_^;)
最悪でもフロントエンドが死んで、２ｃｈ本体は守られる。

◆5kayariAaQ · 04/06/26 22:21

受付嬢が過労死するってことですむんだ　(．．)φﾒﾓﾒﾓ

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/26 22:26

>744
ま、受け付け嬢は数を増やしていけば分散できるし(^_^;)

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 22:29

狙っているな、受付嬢を、、
獣のにおいがする

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 23:14

金払ってない携帯ユーザーなど後回しにして、
PCユーザーのために人大杉の解消を先にお願いします。

**見習い▲ ★** · 04/06/26 23:16

そだね

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 23:19

c-docomo/c-au対策案
docomo：PDC（mova）とW-CDMA（FOMA）を振り分け。
au/tu-ka：WAP1.0とWAP2.0振り分け・cdmaOne/TU-KAとCDMA2000とWINの振り分け
再編案としては
mova：c-docomomova
FOMA：c-docomofoma
EZWAP1.0：c-auhdml
EZWAP2.0（C/TU-KA）：c-aulow
CDMA2000：c-aumeddle
WIN：c-auhigh

**動け動けウゴウゴ２ちゃんねる** · 04/06/26 23:34

>>749
低速端末と高速端末を分ける理由は何なのでしょうか。

**見習い▲ ★** · 04/06/26 23:36

さて次はいよいよ BlackGoat の発注になるわけだが、
機種は Tiger でいいんでしたっけ?
Single CPU の方がいいような気がしますが。。。

**root ★** · 04/06/26 23:39

>>751
安定性を買って、Singleでよいと思います。
そのぶんをメモリ(キャッシュ)とI/Oに投資したいですね。

メモリ4G、SingleCPU、U320 SCSI dual channel、15krpm disk x 2
Ethernet I/F x 2

といったかんじかと。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/26 23:42

>752
ストライピングはしないのかな？
HDD
IDE 7200rpm 80GB
SCSI 15krpm 36G x 2
でIDEをシステムにつかって、キャッシュはSCSI x 2のストライピングとか

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/26 23:43

技術的には枯れてるし、ストライピングの弱点の、耐障害性については
しょせんキャッシュなので、気にしなくていい(^_^;)しかもI/Oは劇的に向上する

**root ★** · 04/06/26 23:44

いずれにせよ、サーバマザーで64bit PCIものがいいです。
枯れた構成という意味では、CobraよりもTigerかなと。

**root ★** · 04/06/26 23:47

>>753
ストライピングは悪くないですね。
ここは正直あぼーんしてもいいものを入れるので。
技術的にももう既に枯れています。

ディスクは15krpm 36G x 2ぐらいをストライピングで使うことにすると、
どのSCSIカードがいいんだろう。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/26 23:53

普通ならAdaptechのRAIDカード入れればいいと思うんだけど・・・・

**root ★** · 04/06/26 23:59

LSI LogicのMegaRAID 320あたりかなぁ。
U160の時代まではAdaptecだけど、U320ではLSIだという人は多いです。

**749** · 04/06/26 23:59

>>750
高速端末の場合、ホイテョイ回線にアクセスしやすいので、必然的にアクセス回数が多くなる。
低速端末の場合は回線の制約からアクセスがあまり多くできない。
あと、高速端末ではパケ定額やパケ割引サービスとの絡みもある。
また、相対的に高速端末＞低速端末な感じでアクセスがある。
PCでも、8月危機の時はブロードバンドや常時接続の普及で鯖が過負荷になったのと同様。（それまではダイヤルアップの低速回線が主流で速くてもISDNだった）

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:03

>758
Polyのラインナップみてたけど、LSIのRAIDカードって
4chの糞高いのしかない(^_^;)１２万もする
Adaptechだと2chのやつが7万くらいなんだけど

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:03

暫定
BlackGoat
Mother bord Dual CPU , 64Bit PCI
CPU Pentium4 2.8G x 1
Mem 4GB
HDD IDE 7200rpm 80GB
　　　SCSI 15krpm 36GB x 2
DISK Controller Adaptech 2200S 2ch Ultra320 64Bit PCI RAID 64MB
NIC Intel Pro1000 x 2

**root ★** · 04/06/27 00:04

amr(LSI Logic)もaac(Apaptec)も、FreeBSDで特に問題なく動作しますね。
これが本筋かな。

Tigerサーバ + ストライピング構成で、
あまり高くならない方向でたたき台を考えてみるか。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:09

つかまって(^_^;)Pentium 4 Dualってないじゃん～
Xeon dualマザーですな

**root ★** · 04/06/27 00:09

>>760
そのへんは、カードまで指定すればとってくれるらしいです。< Polywell

>>761
サーバマザーにつき、CPUはXeonかなと。
システムディスクも2200S(とかMegaRAID 320)につないで、SCSIにするほうがいい予感。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:10

オンボードでLANが２口ついてるマザーがあるけど、チップはどこのだろ？(^_^;)

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:11

>764
ぅぃぅぃ。

システムSCSIにするとなんかいいことあるんだろうか？(^_^;)
むしろ5400rpmのIDEの方が安定な気がするんだけど

**root ★** · 04/06/27 00:18

IDEなシステムとSCSIなシステムでは、普通に使っていても、体感は相当違いますね。
たぶん、ディスクそのものの回転数もさることながら、シークタイムが違うことが大きいようです。

今回の場合だと、例えば/var/logとかは頻繁にｱｸｾｽされるので、
高速なものにしておかないと、全体の足をひっぱってしまうことに。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:19

>767
log取るの？(^_^;)read要求専用なのに・・・・
一時的に取ることはあるとしても、恒久的にとり続ける必要ないと思うんだけど。

**見習い▲ ★** · 04/06/27 00:20

目的が log 取りというのは今一かも　< 理由

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:22

DISK書き込みが頻繁にあるならSCSIの方がええと思うけど・・・・
UNIXのことはよくわからんのですが、一度立ち上がっちゃえば
SWAPとかPageとか発生しない限り、ほとんどアクセスなくなるってもんでもないのかな？

**root ★** · 04/06/27 00:26

ログもさることながら、ページングとかシステム全体のパフォーマンスですね。
ログ収集は全く目的ではないので、目的の本質じゃないし。

**見習い▲ ★** · 04/06/27 00:27

んじゃ　36G x2 でいいとおもいまーす
三本目はいらない

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:30

RAIDにシステムののっけちゃうってこと？
ま、最初はそんなもんかなぁ・・・・
キャッシュ量がどんくらい必要になるかとか、やってみないとわかんないし(^_^;)

**root ★** · 04/06/27 00:32

UNIXの場合、ページングは頻繁に発生しますね(そういうものです)。
で、システムディスクはアクセス量は少ないですが高速アクセスが必要なので、
下記構成がいいかなと。これだと、カードは1枚で済むので。

(構成1)
SCSI RAID card
｜　　　　　　　｜
system　　　data
disk　　　　　disk #1
｜
data
disk #0

**root ★** · 04/06/27 00:34

>>772-773

2本にするのでもいけますかね。
>>774 のsystem diskがなくなるかんじですか。

つまり、72Gのでかいディスクがあるつもりでシステムを組むのか。
コストとのバランスでは、悪くなさそうかも。

**root ★** · 04/06/27 00:36

で、万一バックエンドがあぼーんしたら、しばらくはフロントだけで動かす(今の状態)と。

そういうサービスレベルで動かすのであれば、RAID 0にシステムものっけるのが
パフォーマンス的にも悪くないと思います。なにより、構成がシンプルになるし。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:37

ぅぃぅぃ(^_^;)んじゃこんな感じかな？
BlackGoat
Mother bord Xeon Dual Type , 64Bit PCI
CPU Xeon 2.8G x 1
Mem 4GB
HDD SCSI 15krpm 36GB x 2
DISK Controller Adaptech 2200S 2ch Ultra320 64Bit PCI RAID 64MB(あるいはLSIの同等品)
NIC Intel Pro1000 x 2 (onboad LAN がintelなら、それでもよし)

**見習い▲ ★** · 04/06/27 00:37

ご確認をば、

1) まず 36Gx2 を基本とします
2) 高速性を追求するかめにストライピングします。
3) システムも高速がいいので、これでokです

ってこと?

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:38

>776 >778
いいかんじだと思いますー(^_^;)

つか、考えて見ればストライピングしてるから
72GBなんですねー(^_^;)わすれとった

**root ★** · 04/06/27 00:39

>>778
いいと思います。

**見習い▲ ★** · 04/06/27 00:40

りょうかい　りょうかい

**外野ｧｧﾝ** · 04/06/27 00:42

返事は一回でいい

**見習い▲ ★** · 04/06/27 00:43

はい　ﾊｲ

**root ★** · 04/06/27 00:49

>>777
概ねそんなところですね。< 構成

onboard LANはBroadcomのでも問題ないです(pekoサーバはBroadcomのGigaもの)。
というか、普通のXeonマザーなら通常いまいちなカードは入ってないと思われ。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:50

>784
そりゃそうですね(^_^;)ローコストモデルじゃあるまいし

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 00:51

つか、LANはオンボードの方がええね(^_^;)バスの縛りが少なそうだし＞Gb

**動け動けウゴウゴ２ちゃんねる** · 04/06/27 00:57

LAが馬鹿高くなっている携帯向けサーバではMaxClientsとかを
もっと小さくした方がよさげ。というか、どう考えてもネットワーク
がボトルネックになるはずなのにLAが上がるってことは、
スラッシングしてるってことなので、同時接続数を増やすのは
誰の得にもならんですよ。

**見習い▲ ★** · 04/06/27 00:59

>>787
BlackGoat が投入されて始めて
今回の目標とする機器ょ含めたシステムが出来上がるのに
今を観察して対策するというのに何の意味があるか解りません。

作業は完成後となるでしょう

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 01:02

ところで質問・・・・・
スイッチも同時投入？(^_^;)

**root ★** · 04/06/27 01:03

>>787
MaxClientsを小さくすると、遅い携帯さんがコネクションを握ってしまうので、
全くつながらなくなるですね。
(前のcの頃にかなりこのへんはそうとう試行錯誤しました)

同時接続数は逆に増やしたいぐらいです。

**見習い▲ ★** · 04/06/27 01:03

>>789
その予定

**root ★** · 04/06/27 01:03

で、LAが上がる原因は、キャッシュディスクに対するI/O処理だと思うですね。

証拠としては、メニューが出るところまでは比較的高速ですが、
subject.txtを参照するところでぐっとおそくなり、スレ本体を持ってくるところで
さらに遅くなっています。

で、こいつをバックエンドサーバを入れることで、
フロントエンドから追い出そうというのが、今回の目的かと。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/06/27 01:05

>791
んじゃLANは２枚でOKですねー

**動け動けウゴウゴ２ちゃんねる** · 04/06/27 01:42

>>792
うへ、バッファキャッシュとかほとんど効かないってことですね。
というか、さすがに携帯からの全てのアクセスを受け持つと、
アクセス対象が分散されすぎってことですね。
恐っ。

**root ★** · 04/06/27 01:50

>>794
そういうかんじです。

で、巨大メモリ・高速ディスクなバックエンドを準備しようっていうのが今回の眼目で。

**見習い▲ ★** · 04/06/27 01:51

それでどうなるですかねー
目論み通りに行くのか?
予想よりも素晴らしい結果を残すのか、
はたまた、撃沈か・・・

**root ★** · 04/06/27 01:54

あとは見ていると、PHPの処理に時間がかかっている気がします。

あ、そうか、フロントは前のcと違ってi386なんだから、あれを入れるといいかも。
ちょっと試してみるか。

**見習い▲ ★** · 04/06/27 01:55

>>797
ああーっ

折角重い状態をあえて作ったんだから・・・

**root ★** · 04/06/27 01:55

ということで、これ入れてみようかと。
http://www.zend.co.jp/products/optimizer/

**root ★** · 04/06/27 01:56

>>798
いや、たぶん入れても焼け石だと思うですよ。
I/Oの改善はこれ以上無理だから。

桶屋 · 04/06/27 02:00

楽天を10倍速くしたヤツですね。

**未承諾広告※** ◆TWARamEjuA · 04/06/27 02:00

>>799
php のバージョンが一致しないようですけれども大丈夫なのかな？＠現状は 4.3.6 かな？（最新は4.3.7）

桶屋 · 04/06/27 02:01

ごめんなさい。あっちは別のプロダクトだった(商用)

**root ★** · 04/06/27 02:03

>>802
お、そういう問題があるのか。
まずはダウンロードしたやつを読んでみるです。

**root ★** · 04/06/27 02:07

c-othersに入れてみた。

**root ★** · 04/06/27 02:11

問題なさそうなので、c-auに入れてみます。
入れる作業もままならないぐらい重いので、
いったんhttpd落とします。

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

>>806 乙です。ついでだからc-docomoにもhttpd落として
入れてしまえ～

**root ★** · 04/06/27 02:15

c-auに入れた。

**未承諾広告※** ◆TWARamEjuA · 04/06/27 02:15

自分のところにも入れてみよう（ｗ

**root ★** · 04/06/27 02:17

うそみたいにレスポンスがいい気がする。< c-au

**root ★** · 04/06/27 02:21

c-docomo、これから作業します。
いったんhttpd落とします。

**root ★** · 04/06/27 02:23

c-docomo 完了。

◆5kayariAaQ · 04/06/27 02:24

ずいぶん負荷が下がった。<c-au

**未承諾広告※** ◆TWARamEjuA · 04/06/27 02:25

>>810
LA 値だけでもえらい下がりようですね（驚）

**root ★** · 04/06/27 02:25

この呪文は効果あった模様。
これバックエンド入れれば、鬼に金棒ということで。

**root ★** · 04/06/27 02:30

I/Oもさることながら、時間かかってたのはPHPの処理かぁ。
しかし、Zend Optimizerおそるべし。

**見習い▲ ★** · 04/06/27 02:31

んじゃ様子見て明日の午後にでも
もう少し r.i p.i 止めてまた重い状況作りますー

**root ★** · 04/06/27 02:36

>>817
了解です。
c-docomoはそれでもこんなかんじなので、
また早晩限界を迎えるでしょう。

C.W._WWWWCC.W__WWWWWWWWWW_WWWWW.W.WWWWWWWW__WWWWWWWWWW.W.WWWW_.W
_WW.WWWWWWWWWWCWW.W_WWWW__WW.WW_WW_WWWWWWWWWW.WWWWWW.WWWW_WWWW_.
WWW.............................................................

しかし、フロントエンドを高速化できたということは、
今後を考えるとよかったかなと。

**見習い▲ ★** · 04/06/27 02:38

>>818
ですね、