たまにはプログラムとバグの話（その１）
もうプログラム作るのから離れてだいぶ経っているけど、ネタも少ないし脊髄反射します。
「1銘柄当たりのメモリー領域を誤って4バイト」と指定できてしまうような仕様にそもそもの原因があると思う。「1銘柄当たり1280バイトの作業用メモリー領域」であるならば、銘柄数が決まれば確保すべき作業用メモリー領域も決まってしまうのだから、銘柄数を指定するだけでも充分なはずである。
最大銘柄数は東証の拡張にともなって変更される可能性があります。そしてこの作業用メモリーの領域サイズを計算するには、「最大銘柄数×１レコードのバイト数（1280バイトって奴）」となり、バイト数も必要です。また、１レコードのサイズも将来的に変更される可能性もあります。
で、４バイトというのがまた絶妙ですね。C系のプログラマーの方は、これを聞いた瞬間にピンと来たはず。昔、NASAでロケットを打ち上げる際、FORTRANのプログラムソースで「.」記号を一個忘れたために、ロケットが落ちてしまったという笑えない話がありましたが、こちらも「sizeof(*hoge)」の括弧中の「*」記号を１文字忘れたためにおきたポインタがらみのバグの可能性が濃厚です。これはC系の言語でプログラムを作った人は誰もが一度は通過儀礼としてやってしまうバグの典型であります*1。
とすると、これは設定ミスではなく、このプログラムの該当箇所を書き直した事で起きたのか、それとも元々バグがあったのが３連休明けでアクセスが集中してたまたま発覚した、という事じゃないの？という疑問もわきます。もちろん、４バイトというのはたまたまの一致で、ポインタがらみの問題じゃないのかも知れません。でも、ここまでの説明を聞くと個人的には今回の修正に関係なく、昔からあったバグなんだけど、格好悪いので設定漏れと言っちゃったんじゃないの？と思ったりしてしまいます。
もう１点。
板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。
ここもおかしいですよね。問い合わせが８９件でオーバーフローしたという事は、銘柄数の２万8000銘柄分の情報を常に作業領域に展開しているのではなく、問い合わせの都度、問い合わせを受けた銘柄を随時配列に書き写す仕組みだという事ですよね。とすると、普通はゲートウェイの処理能力＋αを上限として設定し、必要ならばゲートウェイの数を増やす事で対応という事になるはず。最初から２万8000件分領域確保するなんて仕様を作るSEが居たら、なんて無駄な事をしているんだと首を絞めちゃいます。
板情報の問い合わせがあるのは通常数100銘柄程度
とあるように、作業領域は数百件分あれば良く、通常は1000件、ビビリ症のSEでも5000件くらいまで設定する程度ではないでしょうか。あまり多いと、メモリーを無駄に搭載するか、それともスワップを起こしてパフォーマンスを低下させる事になりますので、多ければよいという問題ではありません。まあ、最近では35Mbyte程度どうって事無い量になっちゃいましたが、少なくともここで作業エリアの件数として算出の根拠とするのは、銘柄数ではなく同時アクセス数の推計であるという事で。
というか、これ、「１ユーザーあたりの同時問い合わせ件数は１００件まで」とか、仕様にしちゃったほうが良いかと思います。
事故調査という視点で見るならば、この２つは突っ込みどころだと思います*2。
← 「へぇ」と思ったらクリックを！
