質問・雑談スレ271＠運用情報板
■ このスレッドは過去ログ倉庫に格納されています
差分と書いたのが勘違いされる元だったかもしれません。
前取得時と今の diff ではなく、
レスのあったスレの記録ログの未読分の読み込みという感じです >>60
そう考えるなら、実際にサーバ側、クライアント側を作って提案してみるとよろし。 >>67
現状の負荷というのは、CPUが100%になってるのではなく、
IO処理がネックになってるとかいうものではないのですか？
以前のログでは、CPUには余裕があってIOがボトルネックだったと記憶してるのですが。
今回のはIO処理を減らす意味で、負荷の低減だと思うのですが…… なんに対してのIOのことかは知らんが、
ディスクアクセスなら減らすための仕組みが出来てる。その中にsubject.txtやindex.htmlももちろん入ってる。 >>60
鯖側はその単調増加しかしない「差分の内容」ファイルを、永遠に保持し続けるの？
dat と同じように上限を設けるとして「今どのファイルが有効なのか？」は、どうやって
知ればいいのか？
常に(もしくはおおむね)、subject.txt よりファイルサイズが小さくなるという保障、
もしくは目算は？ >>60
どうやったら一行4バイトで済むのかはわかりませんが、
(「1206276799 1」でも12バイトになるよね？)
ニュー速+やら実況板みたいに一日に10万件近くの書き込みのあるような板だと
その差分ファイルとやらが膨らみまくるんじゃね？
まあ普通のSubject.txtも作ってる時点で専ブラが変な仕様の差分ファイルを
わざわざ取得しに行こうって気にはならんと思うがね。 今回の提案に関する内容をソースにしてみました。
サーバ側に追加する処理は >>52 にも書きましたが書き直すと
if (スレ立て) {
$newThreadId = time;
$newThreadTitle = "新スレのタイトル";
$updateData = pack("NNa*N", 0, $newThreadId, $newThreadTitle, 0);
} else { # レスカキコ (最上位ビットを age フラグにする)
$updateData = pack('N', $threadId | ($age ? 0x80000000 : 0));
}
open(F, ">>updateXX.dat");
binmode(F);
print F $updateData;
close(F);
クライアント側も、Perl で書くなら
@SubjectTxt; # 以前取得した Subject.txt がそのまま入ってるとする
$updateXXdat; # 受信した未読分(Subject.txt を受信してから追記された)のバイナリデータ(4x更新レス数Byte)
$offset = 0;
while ($offset < length($updateXXdat)) # 差分データを全部処理したら終わり
{
$update = unpack('N*', substr($updateXXdat, $offset, 4)); # 4バイト分を抽出
$offset += 4; # 読み込み位置を4バイト進める
$age = ($update & 0x80000000) ? 1 : 0 ; # age フラグは立っているか？
$update &= 0x7ffffffff; # age フラグの除去
for (0 .. $#SubjectTxt) { # スレ一覧を一行ずつ処理
if (index($subjextTxt[$_], $update)) { # 行の先頭で 更新スレ が一致したら
$num = $_; # その行を記憶しておいて
$subjextTxt[$_] =~ s/\((\d{1,4})\)$/'('.$1 + 1.')'/e; # レス数を増やす
last; # 終わり
}
}
if ($age) { # もし age フラグが立ってるなら
$line = splice(@SubjectTxt, $num, 1); # 該当スレを抜き出して
unshift(@SubjectTxt, $line); # 先頭に持ってくる
}
}
# この時点で @SubjectTxt は最新の Subject.txt と同じになっている >>70
今回関係しそうなIOは、ディスクIOとネットワークや、
その関数をコールするときのユーザモードとカーネルモードの受け渡しあたりですね。
ディスクIOは既存で mmap 処理されていれば、それ以上改善は難しいわけですし、
ネットワークIOの送受信に関しては、かなりボトルネックになってる可能性があります。 >>71
差分ファイル(更新スレのIDが追記されてくファイル)の管理に関しては
関係者なら最も効率の良い方法が出てくると思いますが、仮に考えると
一日で1ファイル(日付か曜日でファイル名が決まるなど),
1時間1ファイル (これくらいが適してる？) などがあると思います。
>>66 や他の内容にも書きましたが、差分ファイルには、
その板でレスのあった数ｘ4Byte 分が追記されてるハズなので
If-Modified-Since ではなく Range リクエストでの取得になります。 >>72
スレのIDは time の内容なので int4 のうち31ビット分です。
使われない最上位のビットを age フラグとして 32bit(4Byte) の
バイナリとして考えます。
最もカキコの多い板で一時間で4万弱の書き込み数になりますが、
一時間1ファイルなら最大で160K程度のファイルができることになりますが、
スレの更新を .dat の差分(Range: リクエスト)で取得するのと同じように
全部読みなおす必要はありません うろ覚えなのですが、更新の多い板では、saborin だったかで
Subject.txt の更新をスキップする処理が入ったと思いますが、
その場合でも正しく板の内容に追随できるメリットがありますね。
saborin がSubject.txtじゃなくて他の作業をスキップするなら検討違いですがｗ わかる人にはわかるので追加する必要はないと思いますが一応不足分をフォロー
if ($update eq "\0\0\0\0") { # スレ立てによる更新の場合
# 読み込み位置から \0 までを一気読みする
$newData = substr($updateXXdat, $offset, index($updateXXdat, "\0", $offset)-$offset);
$newThreadId = unpack('N', substr($newData, 0, 4)); # スレIDの取得
$newThreadTitle = substr($newData, 4, length($newData-8)); # スレタイの取り出し
unshift(@subjextTxt, $newThreadTitle . " (1)\n"); # Subject.txt に新スレ追加
$offset += length($newData); # 読み込み位置を一気に飛ばす
} Saborinはindex.htmlとsubbask.htmlでは？ さっき帰宅して今ちとふらふらなので、とりあえず断片的に思うところを。
はずしてたらごめんなさい。
>>78
Saborinはsubject.txt＊以外＊の更新をさぼるものです。
index.html とか subback.html とか html/html とか。
subject.txt の更新をさぼると、ほぼすべての専用ブラウザが発狂するようです。
かつて、夜勤さんという方がそんなことをおっしゃってました。
今雪だるまではsubject.txtの更新は遅延(さぼり、ではなくて)させてますね。
5秒に1回のインターバルで更新だったかな。効果はそれなりにあるようです。
あと、２ちゃんねるのさまざまな呪文(削除系とか)は、datの有無とか
現在のレス数とか、subject.txt を頼りに動いているものが非常に多い気がするので、
subject.txt 自体の更新はあまりさぼれない気がします。
そういう意味で、subject.txt＊ではない＊名前のファイルを作っておいて、
それを使って差分取得(のようなものですね。ほんとの差分じゃない気がするので)
みたいなことをするようにする、というコンセプトは、悪くない考えなのかもしれません。
一般的な板だとsubject.txt は700行ぐらい、大きさで40kBytesぐらいですね。
ちょっとしたdatぐらいかな。ただ、subject.txtは取得頻度がとても大きいので、
うまくやれれば効果は予想以上に大きいのかも。 で、まとめると、
1)subject.txt 自体の構造や更新のしくみは変えにくい
(内部的にも影響がとてもでかい)
2)subject.txt ではないファイルを＊追加で＊作るようにして、
それでやることは考えられなくもない
3)2)は純粋にコスト上昇になる(bbs.cgiの)
4)そして現在の２ちゃんねるは、転送量的にはあまり困っていない(と私は思う)
こんなかんじでしょうか。
ふらふら。 >>81
saborin に関しては完全に私のうろ覚えが原因の勘違いのようですねｗ
私が算出した数値になりますが、ひとつのスレを追うところではなく、
板の更新が多くそれを眺めるような板では、Subject.txt のトラフィックが
50％程度になり、更新が多い＝Not Modified が少なく、gzip でも20〜25KB
程度のレスポンスを常に返している計算になりますが、
１分おきに20回 Subject.txt(20KB) を取得すると仮定すると、20x20=400KB の
データをひとりが取得してる計算になりますが、差分で考えると、たとえ
レスが1000件あったとしても4KBで済む計算になります。
私の概算ですが、現在 mamono が忙しい時間帯は 20Mbps の帯域を使用しる
ようですが、これが半分以下かそれ以上低くなる可能性が高いです。
ネットワーク的に考えると20KBは1464Byte(だったかな？)で多数のパケットに
分割されて送られるわけですが、今回はそのパケット数も激減することで、
ネットワーク装置やドライバレベルでの処理がかなり少なくなると見込めます。 >>82
＞4)そして現在の２ちゃんねるは、転送量的にはあまり困っていない(と私は思う)
これが問題にならないのであれば、bbs.cgi に数行でも変更を加えるリスク
簡単な管理用のスクリプトの追加やチェックする労力
別のファイルへの小さな追記の負荷 (もっと性能の低いマシンでも秒間数万回は処理できるコストなんですけどねｗ)
が少ないものであっても、実現は遠いのかもしれませんねｗ
とりあえず、思いついたことだけ提案してみました。
暇がありましたら、検討リストにでも入れてもらえればちょっと幸せかもｗ >>84
レスどもです。
でも、面白い気もするので、
2ch特化型サーバ・ロケーション構築作戦 Part27
http://qb5.2ch.net/test/read.cgi/operate/1200061619/
こことかにでも、アイディアの種の一つとしてまた。 お疲れ様です。お疲れ様です。
ふと、これが「わいわい」なんだなあ。 と思いました。 で、個人的には今の bbs.cgi では、
html/ の下のファイル(index.htmlの種)を作成するコストがかなり、
でかいような気がするです。
ここを何とかできるアイディアはないのかなと。 >>87
低負荷を意識した実装を書いてみればいいのかな？ >>88
そうですね。
もしよさげな実装ができそうなら、ここ↓あたりですかね。
純粋にbbs.cgiの話だと思うので。
bbs.cgi再開発プロジェクト6
http://qb5.2ch.net/test/read.cgi/operate/1176295715/
現在の実装(MakeWorkFile)は結構、グロテスク((c)SunOSさん)な感じです。
たぶん、大昔の実装とほとんど大差ないと思われ。 >>89
自信作ができたらそちらに投稿してみます。 今の仕様は、適当にどっかの html ディレクトリを見ていただければなと。
http://qb5.2ch.net/operate/html/
datに書き込んだ後index.htmlを作る際に、
書き込み中のdatに対応するhtml/??????????.htmlを
作っているです。
で、index.html で使用する他のhtmlもそこをスキャンして組み込み、
もし存在しなければそのbbs.cgiで作ってから組み込む、
みたいなことをしています。
そんなわけで。 >>91
ネックになってるのは、dat の内容から html に変換する場所ではなくて、
そのあとの index.html 生成過程でいくつものファイルを開かなければ
いけない open 等のシステムコールの方が怪しい気がするのですが、
その切り分けはされているのでしょうか？
dat をhtml にする実装は多分 read.cgi のC言語実装部を改良してXSに
するのが最速な気もします。
上で、open print close 処理が軽いと書いていますが、bbs.cgi での
全ての書き込み処理で index.html を生成してるのであれば、実はそちらの
方のコストが負荷の原因ではないかと思います。(最近この手のベンチ取ってる)
この場合は、パラダイムシフトで生成処理の手順自体を変えることでの
対応が早いような気がします。 ちょっと検証用コードを書いてみますので明日の晩あたりに
bbs.cgi再開発プロジェクト6
http://qb5.2ch.net/test/read.cgi/operate/1176295715/
に顔出します。 >>94
どうも‥‥。
ご無沙汰しております‥‥。 負荷的にも運用ベースではそんなに困ってるわけじゃないでしょ。
手を入れるなら、変な独自仕様じゃなくてXMLベースのものを考えりゃいいやん。
いろんなサービスAPIへの展開が望めるし。 おつかれ・・・おはよう（笑）
オレ様が害虫たちを駆除したおかげで、やっと情報価値のある運用情報板らしい
質雑になって来たな〜（笑）
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWｗｗｗｗWWｗｗ↑→
引き続き運用情報どうぞ♪
↓
↓ 単純にスレタイの入ってないsubject.txtを作ればいいんじゃないの？
他にスレタイの情報が入ったsubjectなんとか.txtってのがどっかにあったでしょ？ スレタイなら、まぁ dat の１行目の最後のエントリに入ってるけどね。 さっき、livecxの伸びをみて
ねらーは本当に現金な奴らだなあ、って思いました。
まあ、俺も人のこといえんがｗ 趣味板はいつになったら正常に戻るんだ？
ギゴナビをDLしてもカキコできんだろうが！
久し振りに大規模で落ちてるので、久し振りに運営板にきてみたー
2ch動かしてる小人さんが、いっぱいいるところだな
鯖落ちスレが、書き込むとブラウザが判明する仕様になってるようですね >>106
User-Agentなら、名前欄に「ﾉtasukeruyo」
半角カタカナを抜くと、fusianasan＋UA表示です。
Monazilla/1.00 (P2/p2.2ch.net; p2-client-ip: 221.221.25.244; p2-user: 128633) >>106
名前欄に
tasukeruyo
ﾉtasukeruyo
でおｋ 名前欄に「ﾉtasukeruyo」でUA表示って
運営板でしか出来ないの？ >>111
まあ、前スレというか何というか・・・（苦笑
乙でした。 >>111
おつです、おつです
最も平和的に、解決しましたねー
本当に良かったです 海外ドメイン規制(nl)。２ちゃんねるビューアを使うと書き込めます。
こんなのあるんだ http://mamono.2ch.net/shar/
この板で書き込みすると120秒待たされるけど、俺は規制されたの？ http://pc11.2ch.net/test/read.cgi/internet/1205037910/l50
ウィキペディアスレでの、'''スルー力'''とは
「みんな、あの子と口聞いちゃダメだからね！！」と言う
小学校の仲間はずれごっこの事である。
まずレスをして、その後にスルーする事で、疎外感を与える手法である。
事実、スレ内で完全なスルーがされる事は稀である。 村上有野似旦那
ttp://blog.arch-heritage.com/images/DSCF7363.jpg また議論といいながら自分の案以外は認めないスメルがこの板からする...
悪用してるのはオマエ ｍ９ >>122
自分の案以外を認めないのもひとつの議論だよ
ただ自分以外の人にそれを納得させることができないのがまずいだけで
俺の案が正しい、それが解らないお前らが悪い、ってのは
駅ホームで見えない悪魔と戦っている害基地と変わらない
俺の案だけが正しいことを周りの大半に納得させることができれば
俺の案以外を採用する必要もない >>122
言い忘れた
俺の案以外を認めない奴を、それだけで頭から認めない奴も
実はそいつ自身が俺の案以外を認めない奴かもしれないよ
一見話し合っているように見せかけて実はそいつも人の案を受け入れる
つもりがないかもしれない
非難すべきは、他人に自説を納得させようという努力をしない奴であって
俺様ジャイアンが悪い訳ではない
ジャイアンが横暴なリーダーシップをとった所で皆が納得していれば
それで議論は成立する 質問です
板の保有スレ数っていうんですかね、圧縮後のスレ数ってのはどこかにお願いすれば変更は可能なのでしょうか。
板設定変更ではなさそうだったのでわからずにここに来ました。よろしくお願いします。 ここで苦情言えば元に戻るって思ってるなんてどこの恥ずかしい板の人間だよ >>114
ああ・・・レス遅れてすまん・・・・
> しね
↓
ああ・・・・そのうちなあ（笑）
WWWWWWWWWWWWWWWWWWWWWWWWWWWWｗWww↑→
それでは、運用情報どうぞ〜〜♪
↓
↓
↓ /￣￣￣￣￣ヽ
/ ＿＿,,＿＿ ヽ
| | へ へ | |
| | ﾟ ﾟ | |
| | ﾑ | | ／￣￣￣￣￣￣￣￣￣￣
| |（￣￣￣＼ | | ＜ うそはうそであると見抜ける人でないと難しい
| | |(二二二) )| | ＼＿＿＿＿＿＿＿＿＿＿
￣､＼＿＿／/￣
ー――一 今日妻がデジカメの写真をCDにフジフィルムの代理店のさくらやでコピーして
デジカメのデータは消しときますかと店員に言われて消した
ところが俺のPCは９８SEで再生できず
損害賠償請求をしたいが
皆ならどうする（妻；怒りくり） >>135
常識なんだけど
ＣＤドライブには相性があって書き込んだドライブ以外では読めない確立があるんよ どういう意味で再生できないのかな？
閲覧ソフトが動かなくても、CD内部に入ってるjpgデータは読めると思うんだけどCD自体が読めないのかな。 >>135
マジレスすると、CDに店員のミスでデータが入っていないのか、
単に保存形式が違って開けないだけなのかがわからんのでにんともかんとも。
前者ならまず店に確認を。
後者なら保存形式に対応した画像閲覧ソフトを。
>>137
ああ、その可能性もあるか。
>>135
板違い
以下のスレッドへ逝けやクズ（笑）
運営系・質雑スレの人が馴れ合うスレ Part166
http://tmp7.2ch.net/test/read.cgi/mog2/1205053287/
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWｗｗｗWww↑→ 自分のうちで、データ取ってから店に行くだろう普通。
そうでなくても店から帰ってきて、
データがCDに正常に書き込まれているか確認してから自分で消したって遅くない。
選択を誤ったのはおまえだ。 ＣＤで読み書きドライブの相性は主に
ドライブ回転速度のバラツキと読み書きヘッドの同期の微妙なズレで発生します
どちらかだけが規格内の中心値なら読めるようですが
どちらも反対方向へズレてると読めないみたいですね
以下から家電品質問なんでもスレに変わります ○きむら
妻はＰＣ使わない
富士フィルムに電話したらメモリ２５６Ｍ必要とのこと（ＳＥは５６ＭＢ、ＭＥでも１２６ＭＢだった）
こういうことは事前にも事後の注意にも書いてない >>146
ネカフェいけよ
弁護士雇うより安いぞ
と、荒らしがスレチ誘導してるから更にレスしてみる >>146
多分CDの内部を覗けば元のファイルが入ってる。
CD入れてCDドライブをダブルクリックせずに右クリックして開く、を選んで
適当に中のフォルダを開いていけばデータがある場所がわかると思うよ。 >>148
ネカフェは妻はいけない（さわれない）
俺は行くが
要するに９８ＳＥ、ＭｅのＰＣを使ってる俺たちを無視してる企業に 怒り！！
ということ
当然ＰＣでバックアップはしてる俺
>>148
ネカフェは妻はいけない（さわれない）
俺は行くが
要するに９８ＳＥ、ＭｅのＰＣを使ってる俺たちを無視してる企業に 怒り！！
ということ
当然ＰＣでバックアップはしてる俺
>>154
帰れクズ
WWWWWWWWWWWWWWWWWWWWWWWWWWｗｗｗWWｗ↑→
他所でやれや・・・・・・・・
↓
↓
↓ では・・・運用情報をどうぞ〜〜♪ >>153
じゃあそのカメラ屋に持って行って文句言ってデジカメにデータ戻してもらえ
多分タダでしてくれるぞ
もういい加減出て逝けやカスども・・・・・
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWｗｗWWｗ↑→
PC板とかいけよカス！
↓ ↓ ↓ じゃあ、運用情報どうぞ〜〜♪ >>158
おれも そう思って 電話したら
店長休暇で 行っておく だと
終わり ■ このスレッドは過去ログ倉庫に格納されています
