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

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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

◆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

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

>>216
i => cの誘導を開始してから、DoCoMoの比率がかなりの勢いで上がった気がします。
あと、深夜はドコモの比率が高いような。他が少なくなるだけなのかもしれませんが。

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

>215,217
非定額でも転送速度の差が結構ありますねぇ
転送量が少なくてもユーザーが一杯いれば僅かな差も塵も積もれば何と
やら状態って事ですかねぇ

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

http://itpress.air-nifty.com/itpress/2004/06/post_1.html
この辺の関係で解約が出てるのかしら＞ボーダフォン「10の約束」反故に
そしてDoCoMoへ、なんて。

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

iMona破綻でドコモユーザが流れてきた？

**root ★** · 04/07/05 17:34

>>213
いまのところ、1)に見えますね。
メモリ不足には見えないです。

ただ、プログラムの「つくり」とか、システム(カーネル)のチューニングで
相当改善できるような気がしていたり。

で、クラシックメニューの場合画像とかはないので、携帯相手でも
転送そのものはそれなりになんとかなっているようです。

netstat -mで見ると、Send queueにデータがたまっている
(送っているが携帯が受け取ってくれない)ものはほとんどなく、
TIME_WAIT(携帯側が待っている)ものがどっさりある状態。

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

c-othersの今日17時ごろへこみは、私がちょっとごそごそしたせいです。
あらかじめ。

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

一回本当の各キャリアのアクセス数を取りたいですね。

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

>>255
ほほぅ　なるほどです、

ちと　考え中。。。

ちなみに、docomo を二つに分けるとしてどんな分け方あるですか?
今までと同様 IP で振り分けたいのですが、

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

>>255
GJ！

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

>>228
今振り分けはIPじゃなくて、携帯が名乗ってくるUAでやっています。
もちろんIPでもできるけど、今はまだやってないです。

もう1台投入した場合、二つやり方があります。

DNSで自然にラウンドロビンさせるやり方と、poundを使ってロードバランシングするやり方。
DNSで自然にやるのは、同じ性能のマシンがいっぱい来るときはシンプルでいいです。
poundだと、こっちに1/4、向こうに3/4とかいう決め細やかな制御ができます。

04/07/05 17:46

おのおののphpスクリプトから、その鯖のキャリアと関係ないキャリアに
対応したスクリプトをばっさり削除するってのは？
docomo専用クラシック、au専用クラシック、とか

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

>>230 続き

DNSの場合: c-docomo.2ch.netという名前に複数のIPアドレスをつける

poundの場合: 設定で振り先のマシンを変える

いずれも、ユーザ側には同じURIをみせることができます。

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

>>230
平均化とか、それを目的にやるのじゃなく
折角のチャンスだからいろいろデータを取って
あれこれ研究するのが目的ですー

つまり　分け方の一例としては
1) 回線速度　a 低速 b 高速
等でわけたいのです。

何か他に分ける方法というか物差しありますかねぇ?

**root ★** · 04/07/05 17:52

>>233
例えばFOMAはこっちでPDCはこっちってかんじですね。
それなら、UAで見ればいけるかなと。

あとはなんだろう。< 分け方

04/07/05 17:56

http://www.nttdocomo.co.jp/mc-user/i/spec/useragent.html

DoCoMo/1.0 → mova
DoCoMo/2.0 → FOMA

これは個人的におもしろそうなんで統計とってほし

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

次の一手は・・・

1) peko 機を移動してこのLANに接続
2) c-docomo を peko 機でそのまま運用(まだ分割しない)
3) これで CPU がへたれかどうかが検証できるはず !?

懸念されることは c の機能がそっくりそのまま改造することなく peko で動くか
かな?

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

>>236
こないだまでcomic4(cobra2246)で動いてました。< cの機能

あのときはLA=50ぐらいで、全部のキャリアを受けてたかな。

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

DOCOMO/AU/otherの振り分けは間違いなくできてるという前提で
LAでなく接続端末数はどうなっているのだろう

待ちプロセス多数でメモリが足りないなら接続受付数の調整で変化出てるとは思いますが

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

>>237
あっ　そうだった、、

◆f0.zuburi6 · 04/07/05 18:34

この間のcobraでは送出待ち多数な状況でしたねえ(接続数とか処理周りに違いはあるけども)。
docomoとauはcobraが必要なんすかねぇ…

◆X7F1FulWvk · 04/07/05 18:47

まだ出ていないようなので、浅知恵で意見致します。

DoCoMoとauの大きな違いは、
端末でキャッシュするかしないかだと思いました。

それから、端末って、ちゃんと「処理完了」のお返事してるのでしょうか？
その辺は解決済みですか？

**未承諾広告※** ◆TWARamEjuA · 04/07/05 18:53

httpd -F on tcpserver という手も残されているのかな？
実験してみたところ、無駄に風呂敷（メモリ）を広げずに動いているみたいです。StartServer も無視。
接続数なども tcpserver 側で制限できるので(-c)、その分 httpd のお仕事も減らないかなぁと。

>>241
TCP レベルのお話かな？＠処理完了のお返事

◆X7F1FulWvk · 04/07/05 18:53

続けて失礼します。

キャッシュがあると、
1.リクエストの間隔が長くなる、
2.一度のデータが大きくなる、
と思います。

誤差程度かもしれませんが、一応書いておきます。

04/07/05 18:54

>>243
？どこからどこまでのキャッシュの話？

◆X7F1FulWvk · 04/07/05 18:58

>>242
どの階層かは思い付きませんが、その辺です。＜TCP

◆X7F1FulWvk · 04/07/05 19:02

>>244
携帯端末内のキャッシュです。

◆/dAlcsdWd2 · 04/07/05 21:15

>>220 docomo2xx、5xxは下り28.8、上り9.6じゃなかたっけ。
ttp://k-tai.impress.co.jp/cda/article/showcase_top/16825.html

そーすっと。ここらへんも関係あるかも。

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

>>247
5xx全てが28.8Kでは無い。
504以降から28.8Kだったっけ
詳しくは知らん。

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

鯖負荷を見ていたら、c-docomoとc-auがパンク状態でc-othersがガラガラ
一応、c.2chの機種別総合アクセス統計が必要かも…。
・D（FOMA/mova）
・au（cdmaOne＆CDMA2000/WIN/TU-KA
・v（V6＆J5/V8）
・PHS（AirH" PHONE/PALDIO brouserphone/ASTELドットi）
てな感じで…。

◆/dAlcsdWd2 · 04/07/05 21:26

>245 そうですね。
ADSLみたいに非対称通信といいたかったわけで。

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

一台増えるけど、
squid---c-docomo---黒山羊
の三段体制とかは？
squidとc-docomoは同居でも良いと思うけど。。

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

>>248
28.8k対応：
50xは504以降。
25xは252以降。
21xは該当無し。
6xxも該当無し。

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

>>251
これ以上の鯖増設は携帯ユーザーの資金でお願いします。

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

　　　　TCP/IP　　　　　　　　　　　　　　　　　　　　　　　　　　　　　28.8k/9600
2ch鯖 ------ GW ----- ﾊﾟｹｯﾄの制御装置とか ----- 基地局 ------ 端末(数千万台)

この構成でTCP/IPの所まで基地局－端末間のスピードで通信してるとは思えないです。
多分どこかでバッファリングしてるはず。

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

今の状態を見る限りキャリアの問題とは違うんじゃないかな？

auもdocomoもほぼ同じアクセス数で同じような負荷

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

>>254
>多分どこかでバッファリングしてるはず。
http://www.hitachi.co.jp/Sp/TJ/2002/hrnmay02/hrn0508j.htm
http://www.hitachi.co.jp/New/cnews/2002/0311/index.html

auは確か日立だったと、
docomoはNECなので、少々違うと思います

t590083.ipgw.phs.yoyogi.mopera.ne.jp · 04/07/06 07:15

>>241に関連したことですが・・・・
「携帯電話は移動する」　→　電波状況が悪くなる　→　強制切断
・・・で、「２ｃｈからのデータが完全に送信完了されない」ために
ゴミが溢れるということは考えられないですか？

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

前々から逝ってるけど中間（ｒｙ

t590083.ipgw.phs.yoyogi.mopera.ne.jp · 04/07/06 07:20

ついでですが・・・・
ＦＯＭＡに限って言えば年末あたりにパケット定額料金の契約者に限定して
ネットワークの混雑状況に応じて個別に帯域制限をかける予定らしいので、
そのことで２ｃｈ鯖→ＦＯＭＡ携帯へのデータ送出が詰まりやすくなることも
懸念されてくるような気がしますです。

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

各キャリアの公式メニューに載せて有料にしちゃえよってのはガイシュツ？

04/07/06 08:37

>>253
それで正解にしよう。
これ以上巻き添いは拙いだろう。

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

>>260
http://qb5.2ch.net/test/read.cgi/operate/1086695147/6

04/07/06 08:40

携帯からの接続に課金してたんじゃないのかよ！
最初はそういう話じゃ無かったか？
いくら鯖増強したって、保つわけないよ。

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

有料でも快適に利用したいという希望者用に●専用鯖併設というのは？

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

今ここはそういう話をしてるんじゃないんです

しかもおまえら全部既出

◆BFzK/mtqM2 · 04/07/06 12:37

docomoの190ってすげーな

**未承諾広告※** ◆TWARamEjuA · 04/07/06 13:28

そういえば、3 人娘の Apache がまだ 2.0.49 のままですよね。＠メモリリークの件

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

サーバのチューニングも大切だけど、PHPを使うのを
やめるのもひとつの方向性かもね。
全部のスクリプトを変えなくても、一部の重い処理だけを
バイナリ化するだけでも全然違うだろうし。

**未承諾広告※** ◆TWARamEjuA · 04/07/06 13:48

>>267
64bits 環境じゃないので関係ないですね。m(_ _)m

**root ★** · 04/07/06 14:10

>>268
プログラムの保守性や開発のしやすさとの兼ね合いもありますね。< PHPをやめるかどうか
個人的には、PHPを少なくとも全面的にはやめないほうがいいかなと思っています。

圧倒的にCPUを食っているのがhttpdなので、
PHPの処理であることはほぼ間違いないですね。
あとは「どの」処理に最もコストかかっているかの見極めかと。

**root ★** · 04/07/06 17:51

ちょっとだけAPC(無停電電源じゃなくてPHPを高速化するモジュール)をc-auでためしてみたけど、
あんまり速くならない模様。

これでZend optimizer, PHP acceralator, APCを試してみたけど、
フリー物ではPHP acceralatorが一番(しかも、相当)いいみたい。

**root ★** · 04/07/06 21:31

さきほどc-othersとc-auで呪文を唱えました。
c-docomoでも機を見て唱えてみる予定。

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

>>272 は「効果があれば」の話です。
しばらくはc-auで様子をチェックで。

内容は >>271 をもう少しまじめに設定してみた、ということで。

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

PHP用プロファイラって無いの？
PHPじゃtruss/traceしても仕方ないか

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

きたく。

>>274
プロファイリングはしたいところですね。
このへん(PHPのプログラムでどの処理が高コストなのかを調べる)は、どうやるのがいいんだろう。