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

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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

**FOX ★** · 04/07/29 15:59

この一時間のcomic6の様子ですが、、、

comic6.2ch.net サーバ
.dat 呼び出し回数 = 59632

deny from 206.223.150.190 #(7465) 12.52%

BlackGoat からこんなにたくさん。。。
これで正常なのか、異常なのか、

**root ★** · 04/07/29 16:03

>>764
15:00(JST)台ですか。
アクセスログを確認してみます。

**root ★** · 04/07/29 16:22

まだログを見ていませんが、今日の昼にやった >>756 の作業が影響しているのかもです。>>764

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/29 17:18

>>763
投げるべきでしょう。結果は期待できないですがね。

◆KAGESsh/NQ · 04/07/29 17:46

「やるべき事」と本質がずれてしまいますが(squid の bug 探し、潰し)…

squid 本家に投げてみるというのも、手かもしれない。
bug track 見てる限りでは、comm.c での assertion faild は出てないみたいですね。
チト source 引っ張ってきて覗いてみたら、

１．何か(すんません、真剣に見てません)の handler 削除のために、
　comm_remove_close_handler() call
２．削除対象探索 in comm_remove_close_handler(), comm.c
　が、探索のキモの部分が for(xxxx; p != NULL; xxxx) になってて、探索対象が
　見つからなければ、for() を抜けて、assert(p != NULL); で落っこちる。

つうことで、多分 memory_pools off の時に、無用な comm_remove_close_handler
call が起こってるんでしょうなぁ。

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

んーそこで落っこちるということはsquid.confで矛盾した設定をしているような気が。

**root ★** · 04/07/29 21:47

>>769
うーむ、具体的にはどのあたりかしら。

**root ★** · 04/07/29 23:22

【.htaccess】読みこみできない【規制作戦】
http://qb5.2ch.net/test/read.cgi/operate/1082968554/868 でポイントした、
http://pc5.2ch.net/test/read.cgi/linux/997328024/182-189 にあった、

>　　　　　　　　reload-into-imsはno-cacheとreloadの命令をIf-Modified-Sinceの
>　　　　　　　　リクエストに変えてしまうもの。つまり無いのに、あるかのように装って差分だけ
>　　　　　　　　送れと言うわけなのれす。

を読んで、reload-into-ims も追加設定してみた。< blackgoat

**root ★** · 04/07/30 01:32

明らかに軽くなった気がして、かつパフォーマンスも前日より出ているので、
今日squidに施したセッティング変更は総合的にはいい方向だったとおもわれ。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/

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

http://qb5.2ch.net/test/read.cgi/operate/1082968554/866-868

refresh_patternのminの値は最終更新日時があると参照されない
＞FRESH if lm-factor < percent, else STALE
ここでSTALE(古い)と判断されたときoverride-lastmodが有効だと
＞FRESH if age < min
＞else STALE
これがテストされる(minの値が参照される)
ということか。

つまり、今まで120delayはまったく効いてなかったということだな。

**root ★** · 04/07/30 11:52

>>773
ですね。お恥ずかしい。

**動け動けウゴウゴ２ちゃんねる** · 04/07/30 14:20

DATをかっさらう悪用で.htaccessで携帯メニューをダウンさせる不届きものが…。
（パクリトロスの2ちゃんねるアーカイブとか言う香具師）
対策しないと、c.2chに円滑に移行出来た所で本末転倒では…。

◆BFzK/mtqM2 · 04/07/31 12:20

ただいま帰宅しました。
とりあえず、i.i2ch.netの方は再開しました。

さてこのあとどうしましょうか？　＞　ひろゆきさん、FOX★さん、root★さん

（１）　現状のまま219.113.242.218から直接差分を取る。
（２）　GlackGoatを通して差分を取る。
（３）　GlackGoatを通して差分せずに取る。
（４）　私家版GlackGoatを作るって、そっちで（２）か（３）

他の私家板（domo2.netなど）にも、開放できるように（４）というのもありなんじゃないかと思ったりして、、、

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/31 12:33

>>776
たぶん

×GlackGoat
○BlackGoat

◆BFzK/mtqM2 · 04/07/31 13:23

>>777
間違えてた　orz

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

BlackGoatが落ちたりしたら、私家版全てが使えなくなるってのモナー。
今回のはミラーでディレイ０秒になってたからでそ。
ディレイ６０秒くらいにしてやれば、問題ないのでわ？

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 00:34

ディレィ調節は本当に意義があるのか？

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 10:01

２ちゃん側にとってはありまくり

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 10:48

実況で重婚

**782** · 04/08/01 10:54

実況でディレイで新着が見られない
↓
新着と同じレスしてしまう
↓
重婚発生
↓
鯖資源の無駄

◆BFzK/mtqM2 · 04/08/01 11:59

そもそもディレイなしでも携帯で実況すれば
重婚しまくると思われ

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 12:11

ディレイ調節は、不便だけで、あまり絶対的な効果はないような？？？

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 13:27

>>785
間にBlackGoatのような
大規模キャッシュがあり、
同一スレについて複数
リクエストがあっても、
最低60秒は更新しない
とかなら有効だと思います。

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 15:10

有効ではなく絶対的な効果があるのか？と聞いているのですが…。
単純な個人ユーザーにとって、２分間のディレイは大変な不便を感じています。

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 15:27

>>783と同様の事になる。
あと、実況以外でも”からけよめ”と煽られる。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/08/01 17:57

絶対的な効果ありまくりです(^_^;)２ｃｈの掲示板サーバの負荷が二桁くらい下がる

◆BFzK/mtqM2 · 04/08/01 18:01

システムが落ち着いたら、c系のディレイ60あたりにしません？
120は結構不便なような気がするのですが、、、

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 20:28

>>787
不満でしたらマシン代を寄付してやって下ちい

◆EA.clAssIc · 04/08/01 23:39

>>root ★さん、
質問なのですが、
現在c.2ch.netにｱｸｾｽすると、各ｷｬﾘｱごとに振り分けられたｻｰﾊﾞにﾘﾀﾞｲﾚｸﾄされます。
DoCoMoなら、c-docomo。(http://c-docomo.2ch.net/z/-/1C/i)
auなら、c-au。(http://c-au.2ch.net/z/-/1C/i)
その他は、c-others。(http://c-others.2ch.net/z/-/1C/i)

1)
このﾄﾞﾒｲﾝ部分をc.2ch.netで見せることは可能なのでしょうか?
つまり、実際はc-docomo2やc-docomo3に振り分けられていても、
ｱﾄﾞﾚｽ上はc-docomoであるのと同じように見せることは可能でしょうか?

2)
例えば他ｷｬﾘｱがそのｱﾄﾞﾚｽにｱｸｾｽしたときに、
そのｷｬﾘｱ用のｻｰﾊﾞにﾘﾀﾞｲﾚｸﾄすることは可能でしょうか?
つまり、auで(http://c-docomo.2ch.net/z/-/1C/i)にｱｸｾｽした場合、
(http://c-au.2ch.net/z/-/1C/i)にﾘﾀﾞｲﾚｸﾄすることは可能でしょうか?

3)
もし上記どちらかが可能な場合、それを行う上で何か不都合なことは発生しますでしょうか?

**動け動けウゴウゴ２ちゃんねる** · 04/08/01 23:44

ここも夏色気分の香具師が多くなってきましたね

◆BFzK/mtqM2 · 04/08/02 01:28

昨日の20時ころからHIT率が下がっているけど、何か設定変えましたか？

**動け動けウゴウゴ２ちゃんねる** · 04/08/02 12:51

5分遅延すれば実況とかチャットとかは機能停止させられるような

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/08/02 16:56

c-docomo2の負荷が突出してる(^_^;)なんだろう？

**未承諾広告※** ◆TWARamEjuA · 04/08/02 17:00

>>796
c-docomo3 の 16:03 JST(00:03 PST+8PDT) の cron で、何かがすっころんでる悪寒ですね。
c-docomo3 の中には入れないのであくまでも悪寒ですけれども。

**未承諾広告※** ◆TWARamEjuA · 04/08/02 17:05

>>797
と思ったら直った。。。
何かがすっころんだのではなく、処理が重たかっただけなのかな？
http://server.maido3.com/pie/graph/oyster246.gif
を見る限りでは正常稼働していたようですので。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/08/02 17:26

もどったーね(^_^;)
http://ch2.ath.cx/load/images/cedf97d7.png
綺麗に負荷が出てるなぁ・・・・

**root ★** · 04/08/03 05:08

海外出張中につきレスポンス悪いです。

>>792
1)技術的にはもちろんできますが、そうすると全部1箇所で処理するようになりますからね。
ちょっと負荷的に。あと、cに何かあったときに全部落ちることにもなるので。
携帯だとブックマークに入れて処理する人が多いようなので、
最初の振り分けのところは、あえて名前を変えて飛ばすようにしていたりします。

2)これは簡単です。

3)2)は不都合ないしそれによる副作用も特にないので、入れてみてもOKです。

でも、意味あるのかな。
わざとアクセスしないと、auでc-docomoにアクセスすることはないような。

>>794
夜の時間とか昼休みの時間は、どうも多くの板の多くのスレにアクセスがいくようで、
ヒット率が下がる傾向にあります。

時間あたりのアクセス数が多くならないのは、ひょっとすると携帯キャリア側で
何か口を絞っているのかも。

>>796-799
例のdaily処理問題かも。ううむ。

**動け動けウゴウゴ２ちゃんねる** · 04/08/03 05:13

>>800
> でも、意味あるのかな。
> わざとアクセスしないと、auでc-docomoにアクセスすることはないような。

そうでもないです。URLを貼る場合に、仕組みを知ってる人ならc.2ch.netに置き換えて貼るでしょうけど、
知らない人はそのまま貼るでしょうから。

◆BFzK/mtqM2 · 04/08/03 12:14

>rootさん

海外出張お疲れ様です。
こまめに水分補給してくださいね。

なるほど、確かにアクセスが増加する昼時と夜は下がりますね。

◆EA.clAssIc · 04/08/03 12:25

>>800
ありがとうございます。
そうしましたら、2)を入れて下さると幸いです。
これは>>801さんも仰っている通り、
誘導ﾚｽがあっても、ｷｬﾘｱが違うと人大杉になってしまう、
という問題の解決のためです。
これにより、以前指摘された、
削除依頼時や誘導時の不便さもある程度解決されるかと思います。

read.cgiや各2chﾌﾞﾗｳｻﾞなど各ﾂｰﾙ側で、
ﾚｽ整形時にc.2ch.netに書き換えて頂ければ問題無いのですが、
それですと大掛かりになってしまいますので、
Love Affair側での対応で何とかできればと思います。
よろしくお願いいたします。

◆EA.clAssIc · 04/08/03 21:48

>>root ★さん、
もう一点お願いしたいことがあります。
●に対応する為に、CURLを入れて頂きたいです。
http://search.net-newbie.com/php/ref.curl.html
http://curl.haxx.se/
現在は、◆BFzK/mtqM2さんのご好意の元、
◆BFzK/mtqM2さんのｻｰﾊﾞで認証を行っておりますが、
そちらも c.2ch.net で行えるようになればと思います。
お手数をおかけ致しますが、よろしくお願いいたします。

◆EA.clAssIc · 04/08/04 02:48

本日、2:40頃に >>497 の機能削減版ｽｸﾘﾌﾟﾄを導入いたしました。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/
にてｱｸｾｽ数と負荷状態の推移を計測して頂けると幸いです。
よろしくお願いいたします。

◆EA.clAssIc · 04/08/04 02:51

>805訂正。
×　本日、2:40頃に >>497 の機能削減版ｽｸﾘﾌﾟﾄを導入いたしました。
○　本日、2:00頃に >>497 の機能削減版ｽｸﾘﾌﾟﾄを導入いたしました。

**動け動けウゴウゴ２ちゃんねる** · 04/08/04 03:44

機能削減版は、テンキー操作デフォなんですね

◆EA.clAssIc · 04/08/04 04:27

>>807さん、
そうなんですー。
ﾊﾟｹ代削減、という枷を外したので。

今後の段階としましては、

1)　表示ｽﾚ数、ﾚｽ数等を設定できるようにする
　○読込数の抑制
　×転送量の増加
2)　最新10ｽﾚｯﾄﾞを、/板/html/xxxxxxxxxx.htmlから取得する
　○ｿｹｯﾄ接続時間の短縮
　×ｷｬｯｼｭﾋｯﾄ率の減少

をやっていこうかと。
それぞれ長所短所がありますので、まずは数値をはじき出すところから。

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

一度に表示するレス数だけでも設定できるようにできないでしょうか？

**root ★** · 04/08/04 05:20

>>805
アクセス数もさることながら、トラフィックがとても減ってるですね。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/

>>803 と >>804 は、ぼちぼちと。

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

それよりもレス全文表示の設定出来るようにして～
省略表示だと見るのがめんどくさ～

**FOX ★** · 04/08/04 15:49

以下のサーバを 2ch LAN (c.2ch.net用)に接続しました。

oyster244
oyster245
banana402

◆BFzK/mtqM2 · 04/08/04 17:36

oyster244とbanana402は何に使うのかな？

◆g4HrV7ViKA · 04/08/05 21:41

ハードウェア不良で掲示板運用を離脱したbanana402、こちらで戦線復帰ですか。

で、blackgoatはあくまでソフトウェア的解決を目指すということなので、
単純な予想
cobra2244 = c-docomo4
banana402 = c-au3 or c-others2

◆BFzK/mtqM2 · 04/08/05 21:48

banana402をBlackGoat2にして、負荷分散で
cobra2244はBBM関連かな？

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

BBMってoyster245でやってたような。（m.2ch.net）
244はドコモの3台目（4台目?）になると予想。

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

auをpeko鯖にして、
BlackGhostの負荷耐性がどのくらいか
チェックするんじゃなかったけ？

**不動楽 ★** · 04/08/08 16:13

c.2ch.net系列のメンテナンスをさせて頂く事になりました。
docomo3のLAが　20040807 16:00　から、
前比2倍くらいの数値を出しておりますが、
この時間、何か設定等変更されましたでしょうか？

**root ★** · 04/08/08 16:42

じさぼけぼけ。

>>818
おお。(今後とも)よろしくお願いします。
その時間は特に触ってないですね。

**不動楽 ★** · 04/08/08 17:19

>>819
お帰りなさい＆よろしくお願いします～
了解です。
先程、16時前後に最新レスに限って、
xxxxxxxxxx.htmlをリクエストするように仕様を変更しました。
BGのキャッシュヒット率の動向に注目したいですー。

**こうすけ ★** · 04/08/08 17:39

16:00と言えば例の定時処理かな？

**root ★** · 04/08/08 18:18

>>820
やっぱり変えたですか。html/の下を持ってきているのかな。

「どうしたんだろう」というぐらい、効果ある模様。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/

**root ★** · 04/08/11 04:02

というわけで、クラシックメニューが元のバージョンに戻ったのを契機に、
バックエンドサーバとしてのpekoサーバの能力を実証実験中。

携帯→2ch運用情報スレッド11
http://qb5.2ch.net/test/read.cgi/operate/1091869644/220-240

**root ★** · 04/08/11 05:19

残りの作業は、

・違ったキャリアのURLへのアクセスから、正しいキャリアのものに誘導するしかけ(難しくない)
・クラシックさんからメールで頼まれた作業をぼちぼち

かな。

で、一両日様子を見た後で、フロントエンドにもsquid入れて、
Apacheがブロックしないように策を練ってみるか。

◆X7F1FulWvk · 04/08/11 11:31

cobra(･ω･)ｶﾙｲﾈ

**こうすけ ★** · 04/08/12 00:09

Peko鯖ってすごいね。。。。

**root ★** · 04/08/12 03:41

http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/

ということで1日動かしました。

まだ継続的な観察が必要そうですが、
blackgoatの倍のヒット率を処理できている模様。

またblackgoat2では、今まで観測されていた
アクセスピーク時におけるキャッシュヒット率の急激な低下=>トラフィックの漏れ出しが
かなり少なくなったようです。

つまり、
ピーク時間に漏れ出るトラフィックが少なくなる => ピーク時間の他のサーバへのdatリクエスがト減少 => 負荷軽減

という効果があったと。

**root ★** · 04/08/12 03:47

>>827
× blackgoatの倍のヒット率を処理できている模様。
○ blackgoatの倍の時間あたりヒット数を処理できている模様。

おやすみなさい。

**こうすけ ★** · 04/08/12 08:19

まちとぴんくを一旦c.2chに復活させて、実際に転送量がどれくらいあるかをみませんか？
とりあえず黒山羊さん1号に飛ばしてみるとか、
もう一台のbananaを黒山羊さん3号にして、別々にプロキシ設定してみるとか、、、

ところでFOXさん、まちも分離の方向でよいのですか？

**root ★** · 04/08/12 11:12

>>829
桃色系をblackgoat1号で処理して統計とるというのは、
仮にPINKちゃんねる側で今のc相当のものを準備する場合、
どの程度の設備が必要かの判断に使えそうですね。

PINKちゃんねるは現在拡大路線なので、これによって必要な設備規模がわかり、
かつ設備に対する効果が有用であるという判断がなされれば、
はれて投入の道も開けるかと。

ということで一時的に期間限定で復活させて、データとってみますか。
blackgoat1号のほうは、昼ぐらいまでにいったんキャッシュクリアして前準備しておきます。

**こうすけ ★** · 04/08/12 11:44

>>830
そうですね。
Banana１台ですむのは明らかだろうけど、
実際にどのくらいの規模なのかいまいちつかめないので、、、

ソースの方はいじっておきますので、準備が出来たら連絡ください。

**root ★** · 04/08/12 11:53

blackgoat側、準備OK。>>831

**こうすけ ★** · 04/08/12 13:11

設定したです。

c-au2(c-docomo1)が重い。。。
どうしたんだろう？

**未承諾広告※** ◆TWARamEjuA · 04/08/12 13:18

ping traceroute それぞれは通りますが、http 、ssh は不出。 ftp 劇重たいですね。。。＠banana404

**未承諾広告※** ◆TWARamEjuA · 04/08/12 13:19

ということで、リブート要請出しますー

**root ★** · 04/08/12 13:19

おつでした。

たしかにようすがへんだ。みてきます。> c-au2

**root ★** · 04/08/12 13:20

数分でログインはできる模様。

>>835
あ、ちょっと待っていただけると。

**こうすけ ★** · 04/08/12 13:21

ログインは出来ました。

**root ★** · 04/08/12 13:21

9:21PM up 21 days, 12:43, 2 users, load averages: 333.31, 283.91, 192.05

**root ★** · 04/08/12 13:26

httpdを再起動してみた。< c-au2

**こうすけ ★** · 04/08/12 13:29

>>840
おつです。

新しく入れたPHPをキャッシュするところで何か起こったのかな？
それとも、変更したもののバグ？

**未承諾広告※** ◆TWARamEjuA · 04/08/12 13:30

>>837
I'm freeze it.(^-^;)

**root ★** · 04/08/12 13:31

なんだかわかりませんが、httpdが超高負荷状態に。
エラーログにはこんなものが。
httpd in free(): error: recursive call
httpd in free(): error: recursive call

**root ★** · 04/08/12 13:33

syslogとかには、ハード異常とかそれっぽいのは見当たらないなぁ

**root ★** · 04/08/12 13:36

その他のログにも、変な形跡はない模様。
更新したところで起きたようなので、アクセラレータとのからみの問題か、、、。

しばらく観察ということで。

**こうすけ ★** · 04/08/12 13:37

やっぱり、スクリプトを入れなおしたときに、何か起こったのかな。。。。

**ぴんく丼 ★** · 04/08/12 13:54

>>830
広告関係でオーナーから物凄いクレームが毎回来るので
出来ればやめて欲しいです(or 物凄く短期間にして欲しい)

頼みます、頼みます、
何度激しく起られたことか、、、

**こうすけ ★** · 04/08/12 13:56

>>847
了解です。
１日限定ならOKかな？
もっと短く？

**こうすけ ★** · 04/08/12 13:57

まずは、２ちゃん管轄の広告を消しましょうか？
あと、可能であれば、ぴんくちゃんねる管轄の広告をだすとか、、

**ぴんく丼 ★** · 04/08/12 14:00

実験でやるなら、やらないで欲しい、
向こうも広告の方は統計とっているので直ぐに変化がわかるから、
完全に分離してくださいー
つまり c.2ch.net からは bbspink.com はどんなことがあってもアクセスしない。

たぶん　そのうち deny等する事になると思います。

よろしくお願いします。

**root ★** · 04/08/12 14:01

>>847
そういう事情ですか。
では、24時間限定でいきましょう。

明日の14:00でばっさり止めるということでいかが。

で、>>849 は、c.bbspink.com (仮)とかを作る方向で考えればいいかなと。
( 参考 >>830 )

**こうすけ ★** · 04/08/12 14:02

了解です。
じゃあ、中止しましょう。

ぴんくちゃんねるで、本当にc.bbspink.comが必要になったら、その時にやりましょう。

**動け動けウゴウゴ２ちゃんねる** · 04/08/12 14:04

書き込む前にリロードしましょうネ

**こうすけ ★** · 04/08/12 14:06

（１）今すぐやめる
（２）１日限定
（３）c.bbspink.com（仮）を作る

どうしましょうか？

**FOX ★** · 04/08/12 14:12

質問です
c.2ch.net を一週間ぶっつづけでダウンタイムなしで動かすには
どうしたらいいのだろう?

さらに一ヶ月だったら?

**root ★** · 04/08/12 14:15

>>850 >>852

了解です。
そこまで理由が明確であれば、「分離する方向で」ではなく「今後完全分離」かと。

c.bbspink.com についてはbbspinkの板などと同様、bbspinkのオーナー・スポンサー方面の意向で。

>>854
私は「明日の14時までに限定、今後c.2ch.netでの復活なし」でよいと思いますがいかが。

**root ★** · 04/08/12 14:21

>>855
系全体として、c系のサービスダウンをさせないように、という意味だと理解しました。

金がかかる方法(力技)はたぶんいろいろあるけど(わりと確立している)、
できるだけ知恵で解決できないか、というのが質問の趣旨かしら。

**FOX ★** · 04/08/12 14:24

>>857
すべての方法の中から、最善手を考えたいです。

「サーバを六台投入すれば一ヶ月もつ」とかが知りたいです。

**root ★** · 04/08/12 14:32

なるほど。>>858
それじゃ、これまでわかったことを下敷きに、グランドデザインを考える必要がありそうだ。

大方針a)落ちないように、専用の機器等を使ってガチガチに固める
大方針b)落ちるものと仮定して、一部マシンが落ちても大丈夫な構成でシステムを組む

が、まず大きな分かれ目になりそうですね。

# 個人的にはb)乗りです。

**root ★** · 04/08/12 14:35

で、「見切り」をどこに作るかが次のステップか。

例: フロントエンドとバックエンドを接続しているネットワークはこわれないとみなし、二重化しない、等

**こうすけ ★** · 04/08/12 14:35

ｂ）でしょうね。

a）は金がかかりすぎると思う。

**FOX ★** · 04/08/12 14:42

勝手にいろいろい仮定して一つの案を出してみると、

仕組み的にはこれまでやってきた方法の延長線上でok
(新しい仕組みを作るにはさらに数ヶ月かかりそうだから)
で、知恵も絞りつくしてあとは若干の性能向上が見込めるだけ、
ということは、物量作戦なのかな?

BlackGoat 二台増設
au banana 四台増設
docomo cobra 四台増設
others banana 二台増設
c.2ch.net banana 一台で独立

これだけあれば九月を乗り切れる

とか、

**root ★** · 04/08/12 14:51

ちと、今日はしばらく忙しいので手短に。

>>862
つまり横並び作戦(当初路線の延長線上でいく)ということですね。
どのパーツがどのくらい必要なのかは、これまでとった統計情報から見積もってみるかんじで。

あと試してみたいソフトウェア的な知恵としては、
フロントエンドにsquidを入れて、httpdが満員にならないようにするぐらいですかね。