メッセージ。 - [日記] Amazon S3負荷テストの問題(Gaucheのread-block)
# [日記] Amazon S3負荷テストの問題(Gaucheのread-block)
Wiresharkでパケットキャプチャを取ってみたら、負荷テストで問題が起こる原因が分かった。どうもプロキシサーバーが上位に送出しているHTTPヘッダのcontent-lengthと、実際に送出しているbodyの長さが一致していないときがあるようだ(content-lengthが65536なのに実際に送出しているデータの長さは8192バイトになるなど)。
なぜこうなっているかというと、要するにぼくのコードのバグなのだが、下位からデータを受け取るときに、単純に(read-block 65536 iport)などとしてネットワークから必要な長さのデータを読み込もうとしているところが間違っている。read-blockは指定された長さ分のデータをポートから読み込むが、実際にはポートに十分なデータがない場合などにいったん指定された長さに満たないデータを返す。つまり、「指定された長さが得られるまでブロック」という風になっていない。
なので、実際にこのへんをコーディングする際には、read-block!を使って得られた結果の長さをチェックし、欲しい長さに満たない場合は必要に応じて繰り返しread-block!を使って残りを得るという風にしなければならない。このへんは何度かプロキシサーバーを実装したときに知っていたのだが、今回コードを組んだときにはめんどくさいから端折ってしまったのだった。ということで、たぶんこれを直せばうまくいくはずだが、朝のコーディングタイムは時間切れ。続きは明朝かな…。
…あれ? と思ったけど、read-block!のマニュアルには「Function: read-block! vec &optional iport start end endian」とあって、取得するデータの長さを指定するというよりも、ベクターを埋めるという感じになっている。これだと、「read-block!したあと得られたデータの長さをチェックして…」ということができない気もする。実はふじさわは、ベクターやバイトデータが出てくるあたりが苦手で、Gaucheの仕様を正確に把握していないのだよね。(以前にプロキシサーバーを実装したときには、read-blockを複数回使って、imcomplete-stringをなんとか連結したりしたのだった。これで正しいのかもよく分かっていない…。そういえば、そもそもこのへんで返すデータの型がstringでいいのかという問題もあるな…)ということで、もうちょっと頑張ろう。
なぜこうなっているかというと、要するにぼくのコードのバグなのだが、下位からデータを受け取るときに、単純に(read-block 65536 iport)などとしてネットワークから必要な長さのデータを読み込もうとしているところが間違っている。read-blockは指定された長さ分のデータをポートから読み込むが、実際にはポートに十分なデータがない場合などにいったん指定された長さに満たないデータを返す。つまり、「指定された長さが得られるまでブロック」という風になっていない。
なので、実際にこのへんをコーディングする際には、read-block!を使って得られた結果の長さをチェックし、欲しい長さに満たない場合は必要に応じて繰り返しread-block!を使って残りを得るという風にしなければならない。このへんは何度かプロキシサーバーを実装したときに知っていたのだが、今回コードを組んだときにはめんどくさいから端折ってしまったのだった。ということで、たぶんこれを直せばうまくいくはずだが、朝のコーディングタイムは時間切れ。続きは明朝かな…。
…あれ? と思ったけど、read-block!のマニュアルには「Function: read-block! vec &optional iport start end endian」とあって、取得するデータの長さを指定するというよりも、ベクターを埋めるという感じになっている。これだと、「read-block!したあと得られたデータの長さをチェックして…」ということができない気もする。実はふじさわは、ベクターやバイトデータが出てくるあたりが苦手で、Gaucheの仕様を正確に把握していないのだよね。(以前にプロキシサーバーを実装したときには、read-blockを複数回使って、imcomplete-stringをなんとか連結したりしたのだった。これで正しいのかもよく分かっていない…。そういえば、そもそもこのへんで返すデータの型がstringでいいのかという問題もあるな…)ということで、もうちょっと頑張ろう。
Comment
Trackback