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

問題はどうやってサーバを増設するかってことかな?

>>931
振り分けってマシンを増やすってことであれば、>>874に有る様に
お金がない状況だから資金調達の問題を先に解決すべきな希ガス。

んで、今想定されているようにc-au1,2,3と横並びに増やしていくのに
対して、モデル世代毎に振り分けるのはどんなメリットがあるんだろ？

みんなが機種変するのに従い、サーバの負荷も旧→新へと移行する
だろうから、負荷バランスの配分に苦労しそうな気がするんだけど。
運営側で鯖移転を繰り返してバランスさせるより、ユーザ側で勝手に
分散してくれる方が効率が良いような。

>>933
スクリプトは共通だよー

>>934 見習いさん
それが一番の問題でしょうね。

いくつか方法は考えたけれど、すべて既出なんだよね。

>>932
バックエンドが来てから出ないとなんともいえないですが、
システムは単純なほうがいいので、単にラウンドロビンにして、
c-docomoという名前がついたマシンを増やせるようにしておけばいいかなと
思っていたりします。

で、問題は既に既出ですが、今後の増設の算段をどうつけるかっていうことで。
仮に携帯用●みたいなものを作るとして、benefitとしては何があるんだろうか。

＞資金

『設置済みp2』を2chが主体になって販売する、とか。
有料レンタル掲示板のノリで。

（1）軽い鯖を使える
（2）ディレイ0秒（可能なのかな？）
（3）スレ立て規制緩和（リモホでなく端末固有情報で規制）
（4）それ以外は通常の●と同じ

つーのはどうかな？

書き込みエラーが起きた後
「〜こちらでリロードしてください。GO!」のリンクを押したら
PC用の方へ行ってしまうのはなんとかならないんですかね

それとも直ってる？

>>941
PC用に逝って、メモリ不足で自動切断される。
bbs.cgiの仕様上仕方ないと思います。

そんなこと言ったら書きこみエラーが起きた後の画面でクリックしたら書きこもうとした内容が記入された書きこみ画面にもどれるようにとかも出来ちゃいそうだしね。
やらないってことは出来ない。やるのが大変、なんだろうけど。>>939-940利用者からカネ巻き上げるようにしたらいろいろ面倒な問題も付きまとってウザそうなんだけどなー

>941
携帯なら普通「戻る」で前のページに戻るだろ。
それから"直す"というか、携帯用にわざわざ"対応"はしてくれないと思うぞ。

ドコモ用の鯖増やすんだったら試しにiMona中間鯖を１台置くとか。

ま、これも増設の資金をどう調達するかによるんでしょうけどね。

>>945
大賛成〜ヽ( ´ー｀)ノ

iMonaの中間鯖にかかる負担て、クラシックより低いのかな？

>>947
ﾊﾟｹ代節約の為zgipで圧縮している場合は、遙かに中間鯖のほうが負荷は高いです
但し定額ｷｬﾘｱの場合は意味が無いため圧縮無しで使っている（このほうがさくさく繋がる）ので、HTML変換が無い分軽いかも

×zgip→○gzip

ある程度のレス毎にレスとレスの隙間にじどうてきに広告が入るようにするとか・・・
んで携帯版●を買った場合 それが表示されなくなる

それと●を持っていると高負荷時でも優先的に処理をするとか

マジメに広告掲載すれば何十万/月の広告収入は可能じゃないの？

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

>>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/

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

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