【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part1 マーリンルージュ >>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系など)を司るとか
と勝手な妄想してみる Bが苦しくなったら、、、その時には共有ストレージをB1とB2で共有するとかして、
ある程度いけるのかな。
キャッシュを全部のフロントエンドで共有しなくてもいいなら、単純にA1〜A5担当がB1、
A6〜A10担当がB2とかすればいいのか。ということでいけそうな気がしますね。
>>300
公園すか。 老いさらばえたひろゆきが公園で威張っている姿が目に浮かぶようです クラシックメインのdelayを120秒に設定したです。
今日一日この設定です。
昨日(60秒)時の負荷はどうなんだろう?
>>307
特に問題になるほどの負荷上昇はなかったです。
(ディレイなしの時でpekoサーバというのを経験してないので、比較論はわからんです)
マシンパワーとしてはまだ余裕あり、という感覚。 鯖の性能が上がったので、ディレイ0秒もありかも? 今日は120秒を実験して、明日は0秒、明後日は30秒あたりで落しどころを決めましょうか?
今夜はサッカーあったので、混雑時の負荷を調べるには丁度良かったのかもしれませんね… root★さん、
2ちゃんの鯖のMaxClientsってどれくらいですか?
家の鯖たん(i2ch.net)がMaxClientsに到達したって怒られたですw >>313-314
どうです?具合は。
>>315
げげっマジデツカ!! i.2ch.net -> c.2ch.net のリンク復活に挑戦してみよう http://c.2ch.net/webalizer/
激しく調整中、、、。
当面、1日に1回、Apachetログがローテートされたら前日分まで更新予定。 >>319
おおっ、いいタイミング。
あとは突然死さえなければ。 iにも入れた。
http://i.2ch.net/webalizer/
当分、iとcはこれしかけておこう。
で、これからリンク復活をためしてみます。>>319 今cのLAは10前後。
昼飯時には、一時的に50ぐらいになったみたい。
>>323の前はoyster246はだいたい8:2でcomic4の処理:cの処理だったのが、
今はだいたい1:9でcの処理してる模様。
しかし、携帯ってのは捌けないなぁ。もっとこうすぽーんとデータが出て行かないかなぁ。
他では見かけない「Sending Reply」のステータスが山ほど。 うーん、電波状況とか不安定だからね。
回線の質が悪いからしょうがないよね。
転送速度も遅いし >>325
だと思います。
「送ってる途中」っていうステータスは、普通にやってるとほとんど見ないんで。
該当部分を抜粋。Wばっか。
WWRWW_RWWW_WWWWWWWCWW_WW_WW_WWW_WWWWW_WWCRWW_WWCWWWWWW_W_WWWW__C
WCWWWCWWWWCWWWC_W_._W_.WWWW.WWWWWWWW_WWCW_._.WW.WW.WW.__WW_WWW_R
.W...W.C.C.W...W...W............W.....W..............W..W....W..
................................W...................R...W.......
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process LA=50でもゆとりで動くあたりが改めてすごいなと。
でも、突然死の恐怖を常にはらんでいるわけで。 いくらFOMAやWINが携帯の中で高速回線になってるとはいっても、
通常のネット環境と比べると段違いだし、安定性にも問題ありますからねぇ。 【Project peko】2ch特化型サーバ構築作戦 Part13
http://qb5.2ch.net/test/read.cgi/operate/1085678587/799
について。
5月末、ほぼ1.5日分のcのデータ。
http://c.2ch.net/webalizer/usage_200405.html#TOPAGENTS
KDDIがワンツーフィニッシュ。上位にKDDI, FONA, AirH"。
もろに「定額制」の影響、という気がします。
今日夕方に上がってくる「一般の人」も含めたデータが楽しみかも。 >>330
あとは今後FOMAがどれくらいあがってくるかでしょうねぇ
しかしこう見ると、2chにおける携帯のシェアなんかもリサーチできそうな(笑) すごく素人考えかもしれませんけど、リクエストにたいして鯖が送るデータ
が詰まることが問題なら、送り出すデータに制限を加えれば少しは低減できない
のですか? でもauで自宅鯖にアクセスしてみると
ケータイでリクエスト
↓
すぐに自宅鯖にアクセスがくる
↓
KDDIのゲートウエイにデータが転送完了
↓
ゲートウエイでHTMLをHDMLに
↓
ケータイにデータが届く
っていう動作をしている気がする。
自宅鯖のBusyLEDが点灯し、
消灯してから1〜2秒後に端末にデータが来ている感じ
が、するようなしないような >>337
HDMLは古い機種だけで、現行機種はXHTMLでしょ?
HDMLゲートウェイ変換は無いのでは。 見当違いなこと書いてました。スマソ
>>324-329を読むかぎり、各キャリアの鯖と通じて端末へデータを送信する
段階でパケットが詰まってるのですかね?
もし携帯キャリアの中継鯖が2ちゃんから送出されたデータを速やかに受け入れ
てもらえない状態になっている場合は2ちゃん側だけの対応では処理しきれない
ような悪寒。
で、遅い相手にネットワークI/Oする人と、
ディスク相手にdatをI/Oする人を分けようというのが、
今回の作戦かなと。 BlackGoat さんとフロント係は物理的に近くなきゃならないんですよね?
つまり同一ラックは勿論のこと
Beckham
Hirosue
BlackGoat
Yukie
DownTown
こんな感じ フロントエンドは
NIC1 ->ルータ(携帯とのやりとり)
NIC2 ->blackGort
BlackGortは
NIC1 ->ルータ(2chサーバとのやりとり)
NIC2-6 ->フロントエンド
って、BlackGortってNICの山になるのか(^_^;) Beckham
Hasekyo
BlackGoat
Yukie
Papaya
こんな感じ >>345
横からすみませんが、GortではなくてGoatなんだけど! ルータ介してやりとりしてもええんやろうけどなぁ(^_^;)BlackGoat<->フロントエンド
>347
あう(^_^;) 一連の処理の流れはこんな感じかな?
(携帯→F)operateの1075887465.datが見て〜
(F→B)operateの1075887465.datをくれ
(B) 探してくる
(B→F)見つけたよ〜
(F→B)httpでGETする
(F)表示処理
(F→携帯)htmlをSEND あっちからの続きバックゴートに必要なのを考えると今出てる最高クラス
の物じゃないとダメそうですね。
・U320 SCSI 15〜20krpmディスク
・フルPCI-X(出れば次世代のフルPCI急行)
・Gigaクラスのイーサカード(しかも大量)
ってここまで来るとタワークラスになっちゃいますね(汗
■ このスレッドは過去ログ倉庫に格納されています