ミッションUD：がん患者を救え！Target：68
49 ：camel@CDOS：
リストにあがっている４サイトの中では一番のヘタレを自認するウチですが、
参考までにウチのページ取得方法とその結果どのくらいUD鯖に負担をかけているか
を検証したいと思います。
ウチの場合は、ページ取得に失敗した場合は10回まで間をおかずにリトライして
います。それでもだめな場合１分待機し、再び同じページの取得にチャレンジ
します。タイムアウトは１分でしたが、現在は３分にしてます。
上記のようなアルゴリズムで運用の結果、今日(9/30)の実績でアクセス数は163回、
所要時間は1時間弱。一方、grid.orgがダメダメだったとき(9/21辺り)の実績で
終日アクセスの結果、計2100回（内タイムアウト800回）程度となってます。
ちなみにこの日はまだタイムアウト1分で運用していました。
最も鯖の負担が重い場合で40秒に1回程度のアクセスが発生している計算に
なります。23000アクセスは極端にしてもウチのアクセス回数も誉められたもの
ではないように思えます。
実際、どの辺がデッドラインかはポール氏に伺うしかないのですが、とりあえず
こちら側でできる対策として、もう少しリトライのインターバルを空けるとかして
鯖負担を減らすことを考えたいと思います。
（とりあえずウチの管理者掲示板に書いたことは忘れてください。ダウン原因は
ほぼ間違いなくH/Wに起因していますので。）
続きます。
参考までにウチのページ取得方法とその結果どのくらいUD鯖に負担をかけているか
を検証したいと思います。
ウチの場合は、ページ取得に失敗した場合は10回まで間をおかずにリトライして
います。それでもだめな場合１分待機し、再び同じページの取得にチャレンジ
します。タイムアウトは１分でしたが、現在は３分にしてます。
上記のようなアルゴリズムで運用の結果、今日(9/30)の実績でアクセス数は163回、
所要時間は1時間弱。一方、grid.orgがダメダメだったとき(9/21辺り)の実績で
終日アクセスの結果、計2100回（内タイムアウト800回）程度となってます。
ちなみにこの日はまだタイムアウト1分で運用していました。
最も鯖の負担が重い場合で40秒に1回程度のアクセスが発生している計算に
なります。23000アクセスは極端にしてもウチのアクセス回数も誉められたもの
ではないように思えます。
実際、どの辺がデッドラインかはポール氏に伺うしかないのですが、とりあえず
こちら側でできる対策として、もう少しリトライのインターバルを空けるとかして
鯖負担を減らすことを考えたいと思います。
（とりあえずウチの管理者掲示板に書いたことは忘れてください。ダウン原因は
ほぼ間違いなくH/Wに起因していますので。）
続きます。
|
|
|
50 ：camel@CDOS：03/10/01 02:13 ID:???
その上で、更なる根本的対策としてTeam 2chとしてのアクセス一本化を検討する
わけですが、実際問題として誰が管理してどう運用するかというのは結構難題だと
思われます。
ポール氏の提案ですと、Team 2chとしてデータセンターを設けてそこでデータを
一元管理するか、アクセスを1日1回に制限するか、または集計サイトの削減という
ことですが、1日1回制限はさすがに厳しいものがあります。またサイト削減という
ことになれば、まあ真っ先に畳むべきはウチという事になるでしょうが、各サイトで
障害を補完しあっている面もあると思うので、４つぐらいなら大目に見てもらい
たいというのが本音。
grid.org側で何らの対策もしてもらえないということであれば、統計データの取得
方法は現在と変わりないということになります。grid.orgの挙動があまり信頼
できるとは言えない状況で、更に取得側の都合（回線障害や契約プロバイダのメンテ、
ウチのようにクライアント側での管理を行う場合はマシン保守や停電対策、等々）
を考えると、１ヶ所で集中管理というのは余りにも心許ないと感じます。
同時に、一元管理ということになれば誰か特定個人に管理を委ねるということに
なり、その人にかかる物理的・心理的負担はかなりのものになると思います。
で、現状での現実的な解として、各集計サイトで取得したデータを相互に融通できる
体制を整えられれば、と考えています。例えば、ウチのプログラムで1時間かけて
先頭50ページしかとれなかった場合、他のサイトの集計状況を見て、そちらで
全データの取得が完了していればこちらの作業を打ち切り、他サイトのほうから
データを融通してもらうような環境を構築できないかな・・・とか。逆にどの
サイトも同じような状況なら、本家が落ちてるっぽいので作業を中断するとか、
まあこの辺は詰めないといけませんが。
まだ続きます。
わけですが、実際問題として誰が管理してどう運用するかというのは結構難題だと
思われます。
ポール氏の提案ですと、Team 2chとしてデータセンターを設けてそこでデータを
一元管理するか、アクセスを1日1回に制限するか、または集計サイトの削減という
ことですが、1日1回制限はさすがに厳しいものがあります。またサイト削減という
ことになれば、まあ真っ先に畳むべきはウチという事になるでしょうが、各サイトで
障害を補完しあっている面もあると思うので、４つぐらいなら大目に見てもらい
たいというのが本音。
grid.org側で何らの対策もしてもらえないということであれば、統計データの取得
方法は現在と変わりないということになります。grid.orgの挙動があまり信頼
できるとは言えない状況で、更に取得側の都合（回線障害や契約プロバイダのメンテ、
ウチのようにクライアント側での管理を行う場合はマシン保守や停電対策、等々）
を考えると、１ヶ所で集中管理というのは余りにも心許ないと感じます。
同時に、一元管理ということになれば誰か特定個人に管理を委ねるということに
なり、その人にかかる物理的・心理的負担はかなりのものになると思います。
で、現状での現実的な解として、各集計サイトで取得したデータを相互に融通できる
体制を整えられれば、と考えています。例えば、ウチのプログラムで1時間かけて
先頭50ページしかとれなかった場合、他のサイトの集計状況を見て、そちらで
全データの取得が完了していればこちらの作業を打ち切り、他サイトのほうから
データを融通してもらうような環境を構築できないかな・・・とか。逆にどの
サイトも同じような状況なら、本家が落ちてるっぽいので作業を中断するとか、
まあこの辺は詰めないといけませんが。
まだ続きます。
板別がバグってのF5状態になってるだけだとしたら、
一元化うんぬんはそう気にしなくてもいいかと・・
一元化うんぬんはそう気にしなくてもいいかと・・
>>51
でも連絡とれないのでは意味がないのかと……。
でも連絡とれないのでは意味がないのかと……。
53 ：camel@CDOS：03/10/01 02:34 ID:???
grid.orgの側でcsvなりXMLなりのデータを用意してもらえるならば、前にも
話しましたがこちらとしては大歓迎です。一括取得ができればアクセスの絶対数
が減りますし、総転送量も大幅に減るでしょう。（現状全データをhtml形式で
取得すると20MB程度になりますが、例えばcsv形式で名前・日付・R・P・Time
程度の情報を抽出すると非圧縮でも1MB程度に減ります。）
加えて、恐らくgrid.org側では統計DBから2chデータを抽出した後、htmlに変換
して送信という処理がページ表示ごとに走っているわけですから、その分の鯖
負担も減るわけでud.org側としても願ったりではないかと思います。
で、もし、grid.org側で専用ファイルを用意できるとかの話になれば、ちょっと
本題からは外れますが、要望したいことが1点。
前日のデータとの突合せで、今は登録者名と登録日付でデータの同定を行って
いますが、改名されると同定が困難になります。改名しても変わらないユニークな
IDがDB上には多分あるはずなので、これを各個人データに付加してもらいたい。
これがあると昨日からの差分作成がずいぶん楽になります。
とりあえずまとまりがないですがこの辺で今日は勘弁。
あ、ついでに言うと私は英語力もヘタレなので直接交渉はできませぬ。
話しましたがこちらとしては大歓迎です。一括取得ができればアクセスの絶対数
が減りますし、総転送量も大幅に減るでしょう。（現状全データをhtml形式で
取得すると20MB程度になりますが、例えばcsv形式で名前・日付・R・P・Time
程度の情報を抽出すると非圧縮でも1MB程度に減ります。）
加えて、恐らくgrid.org側では統計DBから2chデータを抽出した後、htmlに変換
して送信という処理がページ表示ごとに走っているわけですから、その分の鯖
負担も減るわけでud.org側としても願ったりではないかと思います。
で、もし、grid.org側で専用ファイルを用意できるとかの話になれば、ちょっと
本題からは外れますが、要望したいことが1点。
前日のデータとの突合せで、今は登録者名と登録日付でデータの同定を行って
いますが、改名されると同定が困難になります。改名しても変わらないユニークな
IDがDB上には多分あるはずなので、これを各個人データに付加してもらいたい。
これがあると昨日からの差分作成がずいぶん楽になります。
とりあえずまとまりがないですがこの辺で今日は勘弁。
あ、ついでに言うと私は英語力もヘタレなので直接交渉はできませぬ。