[岡崎図書館サイバー冤罪事件] 毎秒1回さばけるべきなんてのは、 ただのロマンにすぎん!?

• Librahack ： 岡崎図書館事件まとめ
  ～マスコミ報道だけでは分からない岡崎図書館事件
• 岡崎市立中央図書館事件 議論と検証のまとめ
• Twitter: #librahack

いや、 いくら 5年前のマシンだからって、 そこまで低レベルでもなかろうよ?

「秒間1回前後のリクエストなんか余裕でさばける設備にしておくべき」的なのが「パソコンキチガイのロマン」にしか基づいてないって。

 
岡崎図書館の MELIL/CS は、 「大量アクセス」 対策の改修が 7月に入ってるんで、 製造元 MDIS の設計思想的には処理能力が下がってるはずなんだけど、 ともあれ現時点での、 1回の応答に掛かる時間を実際に計測してみた。

もちろんバラツキはあるけど、 1秒掛からない。 この画像では、 0.47秒弱。
つまり、

秒間1回前後のリクエストなんか 余裕でさばける設備に なっている のが 現実

 
上の画像は、 Firefox に Firebug というプラグインを入れて、 実際の Web アクセス状況をモニターしたもの。 上半分が本来の Firefox の画面で、 下半分は Firebug のレポート画面。

アクセス先は、 問題になったクローラーがアクセスしていた、 新着図書の詳細情報。 時期が違うので、 異なる本の情報にアクセスしてるけど、 実際の負荷は変わらないはず。
このページのリクエストに対する Web サーバーの応答は、 赤線が引いてある最初の 1行。 (残りの行 --- 16行ある --- は、 最初の応答を Firefox が解釈して、 追加のリクエストを出しているもの。 問題になったクローラーにとっては不要な情報で、 事件の時にはリクエストしていないはず。 )
そのリクエストに掛かった時間のトータルは 565ms (0.565秒) となってるけど、 その内訳が右側の赤い四角で囲った部分。 「待機」 となっている 469ms (0.469秒) が、 Web サーバーからの応答を待っている時間で、 これがほぼ Web サーバーでの処理時間。 (厳密には、 通信の往復に掛かる数十ミリ秒を引かないといけない。)

この結果から、 1秒間に 2回程度はリクエストをさばけるだろうということが、 理解できると思います。

実際には、 この処理時間のうちかなりの部分は、 データベースとの接続待ち時間と、 データベース側の処理時間です。 仮にそれを半分くらいとすると、 さばける回数は2倍ということになり、 1秒に 4回。
さらに、 この Web サーバーのスペックは分かっていて、 CPU にはハイパースレッディング対応の Pentium 4 が使われています。 擬似的に 2つの CPU が搭載されているわけで、 さばける回数はさらにざっくり 2倍ほどあるということになり、 1秒に 8回。 さらに、 HDD の読み出し待ち時間などの空きがあり、 もっと処理可能数は増えるはずです。
まぁ、 以上はすごく荒っぽい推測なので、 毎秒 8回という数字にたいした信頼性はありません。 少なくとも毎秒 2回はいけるはず、 と言うのが精確なところではあります。
※ 本当は複数同時のアクセスをやってみて、 精確な処理能力を知りたいところですけど。 岡崎図書館に対してそれをやると逮捕されかねんので、 あしからず。

 
この事件で、 「毎秒 1回のリクエストに耐えられない低性能」 などと言っているのは、 1回のリクエスト処理に 1秒以上も掛かっている、 という意味では無いんです。
DDoS 攻撃とはとうてい言えない、 設備の能力限界にも遠い、 毎秒 1回程度のリクエスト頻度でしかないのに、 数百回リクエストを続けると Web サーバーがエラーコード 500 を返す (つまり、 Web サーバー側で実行したプログラムが例外を吐いてコケる)、 そんな品質の低いプログラムなんだ、 という意味で言われているのです。