【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part1 マーリンルージュ >>203
XREAで運用してる方もいます。広告無しの有料ですけど。 >>204
それはまた・・・負荷の心配な鯖で・・・ >>1 にも書きましたが今2ちゃんねるのアクセスの50%は携帯からです
アクセス数といっち方がいいかな、大きいのは細切れしか読めないr.iのコール数です。
つまり昔起った read.cgi 問題が再び以前を大きく上回る勢いで襲ってきているのです。
第一回目の read.cgi 問題は C に書き直すでクリアしました。
第二回目の read.cgi 問題は dat 直読みの 専用ブラウザを
普及させることでなんとかこここまで来ています。
さてさて 第三回目の出口はあるのか? わたしがこのスレを立てたときに考えていた事
今も同じですが、
はっきりと出口が見えているわけではありません。
ただなんとなく理論2ちゃんねる学で考えると、、、ということです。
各サーバに置いてある p.i r.i は停止
つまり 携帯からのアクセスは分離して一元管理
かつサーバを増やせばアクセスの増加に対抗できる仕組み
このへんです。 >>206
50%という数値はかなりダウトですが(そもそも何に対して50なのか、
全体のアクセス数では統計的にありえません)、本質はまさにそうですね。
多いところでは、read.cgiよりもr.iの方が多かったところもありました。
今まで見た中では、ネトゲ実況とか芸スポとか。 >>205
負荷もありますけど、転送容量が結構厳しいらしいです。 >>208
それでよいと思うのですよ。フロントエンドを用意しておいて、
各サーバへの負荷を減らす。
cとかはまさにその方式ですね。
ただ、今のcでは全体を受けられない。つまり、スケールしない。
cを横並びにすることを可能にして、スケーラビリティを実現するのが
当面の道なんじゃないかと思っていたりします。
さて、ちょっと別の作業します。しばらく反応割るし。 携帯からのアクセスでクッキー確認画面やめるだけでbbs.cgiコール量が半減するような
気もするが… >>212
bbs.cgi は微々たるものですから
それをたとえ 50% 改善しても全体に寄与する率は
微々たるものかと、
もっと携帯の機能があがればdat直読みできるだけの容量と能力を持った携帯が
現れると思います。
そうすればread.cgi問題も軽減されると思います。
(パケ代が浮く事を考えれば当然)
そこまで来ればなあ。。 >>214
2chの住人で新たな機能を持った携帯を作ればいいじゃん
とか言って叩かれてみるテスト 応分の負担をできるような仕組みを作るべき
といって「また腹黒い」と叩かれてみるてすと お、ついにきたね、マーリンルージュ。
まぁ、昨夏の携帯ロックアウト事件(あのときは.htaccessでしたが)の再来は勘弁、、、と願っておきます。
//携帯→2chスレは大忙しになりそうだな、、、 >>216
ざっと縦読みしてみましたけど、問題は転送量ではなくてread.cgiの呼び出し回数でFA? 今鯖がどうなってるのかよく知らないんですけど、
データベースの鯖はdat直読みに専念し、read.cgiにリクエストがあったら
他の鯖(ゲートウェイ)が解析し、必要なデータのリクエストだけ
データベースの鯖に投げ(ある程度はキャッシュをとりその場で返す)、
それを送り返せば負荷は減りませんか? 叩かれること前提で提案w
各私家版スクリプトのほうで呼び出しの多いホストを常時監視、閾値を超えた
ホストは任意の時間アクセス制限汁。
このアクセスのバイパス規制を行って2ちゃん側の負荷増大を回避。
ではダメなのだろうか。。。。orz まだ 200 そこそこだから
ここまでのログ読んでねー もうでてるよ_| ̄|○
お目汚し失礼しました・・・ ・read.cgi 問題
>第一回目の read.cgi 問題は C に書き直すでクリアしました。
>第二回目の read.cgi 問題は dat 直読みの 専用ブラウザを
>普及させることでなんとかこここまで来ています。
節約では根っこはどうにもならなくなった→継続してサーバを増やす仕組み=おいすたー作戦導入
・携帯問題
>各サーバに置いてある p.i r.i は停止
>つまり 携帯からのアクセスは分離して一元管理
>かつサーバを増やせばアクセスの増加に対抗できる仕組み
>このへんです。
携帯の●・・・
いまのところ使えそうなのはモリタポくらい?
1モリタポで10回リクエストとか(数字は適当)
それとも、もっと各キャリアに負担させるような大きな仕組みを考えてるんでしょうか。 SSLに対応してない携帯が大半だから●は無理では? SSL対応も無論ですが、携帯アプリによる専用ブラウザの普及率などのデータ
を取ることが可能なのであれば、その数字次第では携帯●や携帯専用2chブラウザの推進も十分
有効かと思います。(→コストのほとんどを利用者に振り分け可能)
統計データが取れるかどうかが問題ですが。。。。 ここまでのログ読んだっと。
要は専用のゲートウェイというか、外付けr.iを作るってことなのねー。
http://gateway.2ch.net/r.i/表示投稿数/鯖/板/スレ/表示開始番号
(例:http://gateway.2ch.net/r.i/qb5/operate/1075887465/1 → qb5鯖のoperate板の1075887465スレを1番から表示)
みたいなの妄想してみたり。
ゲートウェイを複数用意して、gateway10.2ch.netだと10投稿づつ表示、gateway25.2ch.netだと25投稿づつ表示、gateway100だと100投稿づつ表示
にすると、環境によって使い分けれて便利っぽそー、と更に妄想してみたり。 無料の私家なんかと併せて一方で
アイモ公式登録しちゃって月額いくらにしちゃえば?
専ブラできてかなり経つのに未だにかなりの数がcgi呼んでるpc見てると
これで結構よくなりそうな気もするけど。
もちろん収入で鯖増強と言う意味だけど。
ここまで書いて
有料化するといろいろ面倒なことが発生すること思い出したから終了...か
スマヌ 省略しすぎて誤解招きかねないのでスルーしてください。。。 >>228 ImonaでUAは変わるかどうかわかりません、ログをとってるかも知りませんが、
その二つをやってれば統計は出ると思います
>>229 鯖いくつ買うのよ!
あ、アプリそのもの(iMonaみたいな)を有料にすればいいのか・・・
使えない機種は切ることになるけど。 >>232
たぶん、バーチャルホストで(w
今まで通りcgiで表示数を調整するのが現実的だとは思いますけど。 ひ(ry)は携帯専用鯖の増設を了承済の前提でなら。。。。ですが、
前半でガイシュツの話しはその増設する携帯専用鯖をキャッシュ専用鯖に
するという解釈でよろしいのかしらん?
それだったらその携帯専用鯖からread.cgiを定期的に読みに行ってキャッシュ。
携帯から専用鯖に読みに行くときはそのキャッシュされた.datから起こした
.htmlを読みにいく感じになるのかな。
ただしその場合は読み込みも書き込みもリアルタイムではなくなるけど。
余裕があればリクエスト数に応じてread.cgiを読みにいく時間を変動させる手も
ありかもしれない。
>>232
別の観点からコストを利用者に振り分けることは有効だと思うので、
データが取れるなら一度取ってみる価値はあると思います。
>>233
アプリが走る走らないのデータも取れるなら越したことないですね。 (あうのアプリがBREWばっかになったら、どうすりゃいんだろ)
(´-`).。oO
へぇ、ごもっともで(´д`)
現在まで得ているで統計データを元に時間帯で切り捨てとか(非難Go!Go! >>237
それも然りですが、新規参入してくるBB携帯も・・・ >>227
ケータイの固体番号(ドコモで言うUIN)で識別できなくもないかな。
機種変したときのためにあらかじめ携帯用のPINコード発行して、
専用設定ページで再度固体番号の登録とか。
ボーダフォン0xでは無理ぽだけど。 >>240
それをDBに登録するってこと?
それなら携帯の規制と絡めて、携帯から2ちゃんを利用する場合は完全登録制
もアリなのかな。
無謀ーダフォンはもうだめぽだから切り(ry >>236
京ポンみたいにread.cgiが読める機種が出てくれば、アクセス数の多い板から順次r.iを廃止してもいいと思うけど、近日中にr.i完全排除は嫌かな。
1分間に一定数以上cgiが呼ばれたら、「高負荷で読めません。空くまでまってね。リロードすることも負荷かかります。」と表示して、高負荷時の書き込みみたいに、読み込みを刎ねることはできないんですか? >>241
●のDBにね。
どっちみち携帯の場合は固体番号でID作ってるくらいだし、
UINと●IDの関連付けをすれば、難しくないような気がする・・・。
んーどうだろ。 >>242
それが「人大杉」だと思うわけですが
>>243
んーたかが携帯(されど携帯ともいう)ごときにそこまでコストかけてくれる
のかという疑問も(>>236)
ただ有料コンテンツとしての扱いならそれもありだろうけど。
お金取る以上はボーダ0xのような端末でも出会い系の登録システムのような
ものを導入すればDB登録=●IDとの関連付けも可能かもしれないね。
規制するときはDBでバッサリで桶なわけだし。 ありゃ、寝てる間に事態が急変してる。
やっぱりi→cは早計でしたか。どうしたもんかなぁ。
んで現実的に考えれば、やっぱりc.2ch.netの鯖増強がメインになるでしょうね。
あとはiMonaなどの携帯用ブラウザでしょうかね。
有料化云々は「ドコモがコミュニティ系を認めていない」「もばいる2ちゃんねるが
頓挫した」と言うことをまず念頭に置いてから議論した方がいいと思います。
独自で携帯に課金を行なうにしても、きちんとした課金サーバの仕組みを考える
必要があるし。 >244
人多すぎって手動でread.cgiを切った状態では r.iの呼び出し回数減らすなら、c.2chの初期設定値変えたらどうだろう。
1回に読むレス数を10→30
省略される行数8→12
一回に読むスレの数30→50 >>248
そげなことしたら、パケット定額にしてない機種は、パケ死する〜。
c.2chからr.i呼び出されてないし。 色々探ってて>>14さんにあったp2というのを試したんですが、
テスト: http://pantomime.main.jp/p2/index.php (携帯アクセス可)
なんかコレ普及させて負荷分散させればかなりread.cgi問題は払拭される予感…
>>249
設定で増やしたり減らしたりできるから大丈夫。
その事を知らずに、たくさん読んでるのに10レスずつ何度もアクセスしてるユーザって多いと思うんですよね。
省略にしても同様。
なんどもアクセスするより一度にまとめて取得したほうが鯖にもパケ代にもやさしいかと。
#c.2chとr.iの話は間違ってたみたいでごめん >>250
c.2chを複数鯖で運用するのと同じですよ。
運営側が考えてるコトといっしょ。
p2を携帯ユーザに普及させるのは難しいとオモうけど。
>>251
初心者さんはデフォルトのまま使い続ける場合もあるので。
それに携帯のweb表示メモリにもよるので、あまり多くするのはちょっとね。 そいや声優板、auでr.iから見てると>>1とかのリンクに飛べなくなってるんです
けど、ガイシュツでした? 携帯からユーザーはパソ所有してないとかもあるだろうから、p2のスキルなんて
全然ないんじゃ… 確かに…ユーザー名で管理とかある時点で一般向きではないかもです
俺は俺個人で使っていきます。お気に入り新着チェックとかものすごいパケ代が浮くし。 名前とかパスワードとか全然解らないでつ(´・ω・`) >257
禿しく同意。こちらもパソコンありません。
(´・ω・`) そうか、パソない人にはやくにたたないのね…
スンマソン 新着チェックなら クラシックメニュ(c.2ch) にも「自動しおり」というのがあるけどね。
クッキーに対応してないとダメだが。
あと履歴編集が出来ないのよね。開発途中で止まってる。 結局imonaやc.2chタイプが受け入れられやすいと。 ちょっと時間無いので3桁以降のレスほとんど読んでないけど
レス2桁台後半ででてるのでおkだと思う。
その方向で煮詰めれば〜なんてシロウドはおもっちゃうのね。
>>260
いろんな設定できるけど、保存できないんだよねぇ。
どっかのサイトみたいに、初めにパス入れる(あるいは入力済み専用ページをブクマク)と
設定を読みこんでくれるようなのだととっても便利だけど。
UINででもいいし。まぁこれはスレ違いか。 >>262
設定はurlに反映されるので、設定が終わったらブックマークしないとあかんよ。
自動しおりの情報はクッキーに記録されるけどな。 >>251-252
全角表示・レス全文表示・AA表示で20レス30レス表示にするとやたら
重くなったりページサイズオーバーになったりする事がある。
多レス読みたい時は携帯青春もあるし。 >>263
書いてから思った。
いつもスレ読みこんでから見づらいなーって変更してるけど
一旦TOP表示してそこで設定して保存させたのをブクマクすれは問題無くつかえるのね。。。
しおりはだめぽか。 しおりは、au,tu-ka,airH"だけだったかな? (ダダッダーダダッ♪ダダッダーダダッ♪ダダッダーダダッ♪ダダッダーダダッ♪)
ザンボっスリー ザンボっスリー 2ch検索なら、ログを全部持ってるし課金の仕組みもあるから
そことうまく絡められないものかな。 ここまで読み飛ばす(あひゃ
読み込み (携帯 => i[1-4].2ch.net <=> 串(キャッシュ) <= 各板)
1.携帯からi.2ch.netを開く
2.i.2ch.netはランダムにi[1-4].2ch.netへリダイレクト (squidを使っていた頃のsakura.mikage.toと同じ)
3.i[1-4].2ch.netは各板から串(キャッシュ)経由でDATを取ってくる
書き込み (携帯 => 各板)
1.名前・メール・本文・板・キー・戻り先urlを各板の携帯専用bbs.cgiへ投稿
2.書き込みが終わったらpostされた戻り先urlへリダイレクト このスレの最初のほう読めばわかるとオモうけど、
c.2ch(クラシックメニュー) は独自にキャッシュとってるよ。
問題になるのは転送量とか、いくつの専用鯖設置出来るかだね。 他の鯖同様にキャッシュをRAMに格納すれば処理は軽くなったりするのかな? 素人考えでスマソだけどそろそろ携帯用閲覧ソフト新規開発してもいい時期
に来てるんじゃないかと思います。
この板にふってみればいい案が出てきそうですね。
携帯アプリ
http://hobby6.2ch.net/appli/
>>274
携帯アプリは、iアプリだとアプリを落としてきた鯖にしか接続できない
(auでも最大3つくらいかな、)なのでiMonaタイプ以外に作りようがないわけだが。
まぁ同じようなソフトでもいくつかあったほうがいいとか
iMonaの作者さんが最近見当たらないので別の人に作ってほしいというなら別ですが、 >275
そして2chアクセスのキャリア占有率1位のauは作れないんだよね(^_^;)brew ここでちょいと携帯などなどの情報まとめ。
●au
問題のパケット定額は、WIN対応機種のみ
WIN対応機種は3機種。
W21H→アプリ機能なし
W11K→JAVA○ BREW× imona○
W11H→JAVA○ BREW× imona○
WIN以外の機種は軒並みBREWになってきてますので
WINも今後出る機種はBREWになると思われます。
最低定額プランで8200円
●docomo
あと数日で、パケット定額開始。
対応はFOMAのみ。
最低定額プランで1万円ちょっと。
●AirH"
月4000円ほどで、PCからも携帯からもネットが使い放題
最新機種ではOPERA搭載なので、PCでのネットサーフィン
と同じ画面が見れる。
●vodafone
個人でも簡単に有料でアプリ販売ができるサービスが2社で
始まったので課金はしやすいかも。
http://appget.com/vf/pc/
http://www.javalive.jp/ で、アプリ開発ですが、、、
imonaスレ、p2スレは、ソフトウエア板。
携帯JAVAスレ(MIDP,DOJA)はプログラム板。
こちらに頼ったほうがよさげ。
携帯アプリ板にあるのは、初心者スレ、質問スレなどだけ。
アプリ板には、開発者が少なく、ゲーマーがほとんどのためだと。
>>9、>>12に書いたときと状況は変わらず、新しい2chビューアは開発進んでなさげ。 これを組み込むという方向は無いんでしょうかね。
普通のapacheモジュールとして組み込むだけだし
r.i以外の名前でテストすれば良い気がしますが。
http://2ch-tool.net/mirror/mod_readcgi.zip ちとご相談
c2.2ch.netってまだ存在してますよね。
そっちに、一時誘導ってあり? c2ってhe上のバーチャルホストですよ、、
まぁ、まだ消えてはいないようだし繋がるけど、
ちょっと危険かと 独自キャッシュのc.2chがメインになるってのは
長期的な流れとしてOKだとして、
どうやって、負荷分散するかってとこっすよね。
質問ですが、
複数のフロントエンドサーバ(5-10台) で
Suma 見たいなやつを HD 代わりに共有できるような
仕組みというか機械あるんですかー?
suma 見たいに巨大な容量である必要はないんですけど、
Docomo 用フロント -------|
au 用フロント ----------共用のHD
j-phone用フロント --------|
その他用フロント ---------|
が全部一つのバックエンド(datを cache)につながっているような感じ。 それを拡大していくと、2ちゃんのdat一元管理ができる?
今の各サーバが一つのHDを参照する。 ほんじつ体調不良にて自宅療養中、、、。
>>285
ブレードサーバ+専用ストレージ(例えばSuma)でできるんじゃないかなと。
というか、とても普通の解ですね、それ。 >>286
ディスクのI/Oキャパいっぱいになるまでは、できるでしょうね。
携帯の場合「どばっと一気に」ではなく「ちろちろが回数多く」なので、
>>285 のような解決方法は、とてもよい気がします。
Polywellもそういう製品持っていると思う。 まぁBladeまでいかなくても(少し高いし)、通常の1Uサーバ数台で
1台のストレージユニットを共有することは、比較的簡単にできるんではないかと。 >>286
究極は
datの読み書き専用サーバ(ストレージ?複数設置)
↓↑
cgi処理用フロント
(PC用、携帯用それぞれ入り口ひとつで複数設置で分散・冗長構成)
ですかね・・・。 ふむふむ
一台で共有するということは、各掲示板サーバの負荷を減らす
目的が第一で、キャッシュさせよってんだからなんだけど、
この線ってことですねぇ 共用のHDDまで作らなくてもいいんじゃないすかねぇ、、
携帯関連のアクセス元がau,vodafone,docomoの3台になるだけで、
十分効果はあるでしょうし、
逆に共用HDDのせいで、携帯系の表示速度のボトルネックになる気がするです。
そこで4-wayCPU+各キャリア専用HDD搭載サーバーですよ と。
つかやはりキャリアごとに専用のサーバーを用意するのが近道かもですねー >>292
ふむ。
とすると、両氏の折衷案として、
・4台のフロントエンドマシンA1〜A4を準備する(DoCoMo/au/Vodafone/そのほか)
・それら4台のマシンから参照される、datキャッシュ用マシンBを準備する
てなかんじかなぁ。
これなら、Apacheのmod_proxyとか使えば、確かに価格張らないで済むかも。 A: Banana、苦しくなればDNSラウンドロビン使って横並びでふやす
B: Tiger or Cobra
っていうかんじかなぁ。
ようは、共用HDDではなくて共用キャッシュマシンを準備するというかんじで。 四台のフロント一台のバックとした場合に
フロント --- バック間の転送に関して
1) ネットワークを介しやる (internet 経由)
2) 裏ネットワークでやる (ケーブルでつなぐ)
3) HD としてやる (suma 見たいな形式)
でコストどれくらい違うですかねぇ
荷造り・発送・荷解き 含めて考えて >>295
うんこ れがよさげ
私が共用きゃしゅマシンを担当したい。 >>296
コスト、とひとことでいってもいろいろかなと。
価格、手間、対性能比、など。(もちろん、それをわかったうえで発言してると思いますけど)
まず、bananaにもう1発ネットワークカード刺して裏ネットワークを作って、そこで2)でやるとすれば、
(Tiger/Cobraはネットワークカード2発ついてたはず)、1)と2)の価格的コストはほとんど変わりません。
ということで2)と3)での比較ということになると、
より信頼性を上げてパフォーマンスを出そうとするなら、3)かなぁ。
FC-AL接続か何かで、複数のマシンで1台のストレージを共有すると。
でも、これは値段それなりにします。
今回程度のシステム(単にキャッシュを効率よく共有したいだけ)なら、
そこまでしなくても、価格が安くて済む2)あたりで十分な気がします。 >>297
おいしいところを持っていこうとしてますね(す。
>>298 にも書きましたが、汎用マシンでやるなら
>>296の案2)を>>294-295の路線でやるのがいいかなと。 目的をまとめてみると、、
1) 携帯からのアクセスは別サーバに隔離して各BBSのサーバの負荷軽減
2) キャッシュすることによって、トータルなコスト(traffic=お金)の軽減
3) 快適にするために横並び拡張性は最初から考慮して設計
4) たぶん来年にはフロントは10台以上になっているかも、
5) ひろゆきが公園で威張れるネタ作り。 >>300
すると、r.iやp.iは廃止ということになるのかなぁ・・・ 携帯で成功したら、PCにも何かフィードバックできればいいっすね。
裏ネットワークは、各サーバ間の情報伝達(BBx系など)を司るとか
と勝手な妄想してみる ■ このスレッドは過去ログ倉庫に格納されています