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

広告ったって、出会い系だけでしょ、どうせ

>>948
強力な鯖で動かした実績がないので、どれだけ裁けるか不明ですね〜
HDDのアクセスが多いのは変わりないと思います。

携帯アクセス用バックエンド Black Goat (黒山羊さん) 到着でーす

メールしました > 管理人、root ★さん。

>>954
ログイン確認しました。
構成は三姉妹と全く同じでした。(Prescottではない)

作業に入ります。

おっ、ついに来ましたか〜
実験は一番軽いc-others？一番重いc-docomo？

>>956
c-othersで機能構築・試験
c-auで設定をチューニング
うまくいけばc-docomoを入れてさらにチューン

っていうかんじかなぁ。

了解です。
受け付け嬢は簡単に改造出来そうだけど、黒山羊さんはちょっと時間かかりそうですね。

>>958
シンプルにI/O業務を分離するため、まずはプロキシ方式で動かしてみようかなと。
つまり、php.ini的にblackgoatの中側のアドレスをproxyにするだけ。
で、c-xxでのdatキャッシュはしないことにすると。

120秒判定のところがきちんとできるなら、これだけでかなりいけると思うけど、どうかなと。
もしこれで転送量やアクセスリクエストが増えてしまうようなら、そのときは別途考えると。

クラシック本体をバックエンドに持ってきて、フロントを介して携帯とやりとりするのかな？

>>960
はい、最初(Tigerサーバ/w SCSI stripeが入る前提だったころ)は、それも考えていました。
で、各フロントエンドは、リバースプロキシをすると。

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

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

1)方式1

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

2)方式2

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

まずは、負荷かかるかもしれないが、（2）を試して、
その間に（1）の準備をしましょうか。

>>962
そうしますか。
なら、一番苦しいとこからやんないと意味ないですね。
c-auやc-othersは何とかなってるから、自動的にあれかぁ。

今夜は、たぶん儀式まで。
で、明日深夜あたりにテスト開始の見込みで。
(明日は終日外出予定のため)

一番重い所で様子を見て、次にauも（2）に変更してまた暫らく様子を見ていく。
その間にothersで（1）を構築する感じですかねー

（1）の本格的構築は週末からですね。

関係者の方々、乙です。しかしc-au、激しく重いです(´・ω・`) 　

携帯を使った直接課金が大変ならば、利用者の手間はかかりますが、PCから
携帯用のユーザ名とパスワードを売って、鯖代にあてるとか、次善策はないですかね？

携帯向けに２ｃｈを解放する（ぴろゆきの）思惑なり、狙いがあるのでしょうけど、
想像するに、今のところはできるだけ金銭的コストをかけずに携帯ユーザー
を引き留める、という方針なんでしょうか。

>>966
こっちにでもカキコしろや。
★携帯からのアクセスを議論するスレ2
ttp://qb5.2ch.net/test/read.cgi/operate/1086695147/

書き込みが絶えて久しいが…。

>>967
誘導したつもりかもしれんが、ちと違うと思うぞ？

＞携帯からのアクセスを議論するスレ2
＞現在運営側では携帯用専用サーバを導入することにしていますが、
＞それまで時間はかかるのは避けられません。
＞ここでは専用サーバ導入までの間どういう対策を行うのか、を議論するスレッドです。

よって>>966のような提案はこのスレで受け付けるのが妥当だと思うが？

>>966
スレに目を通せばわかるように、現在中の人とボランティアさん各位が
がんがって携帯専用鯖の調整に日夜奮闘している最中です。
導入して間もないこともあり、試行錯誤しながら最善の調整を目指して
いろいろ実験しながら調整している段階なので、実験〜調整が完全に終わる
までは携帯からでも利用できることに感謝しなければいけないと思いますよ。

>>969 いや、966の主旨は、ボランティアの労力を否定することではないと思われ。ただ、プアな環境での対策では限界があるから、抜本的な対策を望んでいるのでは。


しかし鯖の維持が大変でひろゆきのメリットとないなら、単に携帯悪禁にする選択肢もありだな。

結局こういった問題ってハ〜ドウェアのレベルの問題でしょ
一番悪いのは電電公社だとおもいまつ
デンデン氏ね

p2本スレに携帯しか持ってない人の為に無料でp2をレンタルしてくれてる人がいたね

次スレ

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

>>960-965の件でメール発射しました。＞◆BFzK/mtqM2さん、クラシックさん

ごくろうさまでした

>>974
とりあえず、コピー＆確認終了ですー

>>976
りょうかいです。
んじゃ、もうちょっとしたらc-othersあたりからごそごそしてみます。

c.2chで鯖移転が反映されて居ない板があるのですが…。

c-others、切り替え完了。様子をチェック中。

c-auを乗せると、LAがこの時間で80超えてしまいます。
やっぱり、PHPをBlackGoatで動かすとだめな予感。

PHPは三人娘側で動かさないとむりぽですね。

>>980
鼻薬を効かせてなかったかもしれないことが判明。
Apacheをバージョンアップして、あとでもう1回やってみるか。

やっぱだめですね。

・PHPの処理
・ディスクI/Oの処理

の「2大重い処理」を分離分割しないことには、どうしようもなさそう。

ということで、すべてを元に戻しました。
さて、どうすべか。

やっぱり、だめぽですか。。。。

ｐｈｐ処理をフロント側へ移すように改造しますか

>>984
そうできますか。

・フロントエンドでPHP専門
・バックエンドでディスクI/O専門

というのが、よいように思います。

そうしておけば今後、

・フロントエンドは横並び
・バックエンドはストライピング等の高速化とか、URIごとに別のバックエンドに依頼するとか

にできるので。

バックエンドのキャッシュ作成にphpなりの処理が必要な気がしますが、そこはどうします？

>>986
バックエンドのキャッシュはApacheのProxy+Cacheでまずは十分なきがします。
これで動かしてみて、転送量をチェックするのがいいのではないかと。

じゃあ、フロント側は、差分うんぬん考えずに、各サーバにxxxxx.datを取りに行けばよいのかな？

>>988
それがいちばん楽ちんですね。
その時にPHP側でProxyを指定することって、できるんでしたっけ。

>>989
うーん、やはりproxyは、apacheの方で設定なのかな？

今一番すいている時間を狙って、一時的にバックエンドclassic、フロントはpoundと
いう構成を試しています。

つまり、最も単純な構成です。

しかし、LAが既に70近いです。

ただ、この構成だとフロントエンドはほとんど完全に遊んでしまうので、
フロント側でもうまいキャッシュ(ディスクキャッシュかな)をやってみると
いいのかもしれないです。

確かに、フロントの負荷がほぼゼロってのはもったいないですね。

>>991
フロント側は、Apacheのリバースプロシキ＋キャッシュってできるのかな？

c-others＆c.2ch.net飛んでますか？

>994
c-others落ちてますね。。。

またSONYか

すいません。。>996は誤爆です。スイマセン。。。

（・∀・）ﾆﾔﾆﾔ

次スレ

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

□□□□■□□□□□□□□□□□□□□□□□□□□□□□□□■□□□
□□□■□□□□□□□□□□□□■■■■□□□□□□□□□□□■□□
□□■□□□□□□□□□□□□■□□□□■□□□□□□□□□□□■□
□□■□□□□□□□□□□□□■□□□□□□□□□□□□□□□□■□
□■□□□□□■■□□□□□□□■□□□□□□□□■■□□□□□□■
□■□□□□□■■□□□□□■■■■■□□□□□□■■□□□□□□■
□■□□□□□□□□□□□□□□■□□□□□□□□□□□□□□□□■
□□■□□□□□□□□□□□■■□□□□□□□□□□□□□□□□■□
□□■□□□□□□□□□□■□□■□□□□■□□□□□□□□□□■□
□□□■□□□□□□□□□□■■□■■■■□□□□□□□□□□■□□
□□□□■□□□□□□□□□□□□□□□□□□□□□□□□□■□□□

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。