アカウント名:
パスワード:
トラフィック生成して高負荷状態作るだけでも面倒そうだし
そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。googleで見つかった順ですが、 diversifEye [empirix.co.jp] とか WebLoad [quality-net.co.jp] とか Web Capacity Analysis Tool [microsoft.com] とか。
あと、この手の高負荷時のソフトウエアバグはOSに問題がある場合を除けばファイルや共有メモリなどの競合(race condition)に原因があるものなので、テンポラリファイルや名前付きイベントの名前の生成方法など、時間をキーにしている部分を重点的にチェックしていくとよいです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
高負荷時の検証作業 (スコア:2, 興味深い)
トラフィック生成して高負荷状態作るだけでも面倒そうだし、
単純負荷じゃ駄目っぽいし。
Re:高負荷時の検証作業 (スコア:5, 参考になる)
トラフィック生成して高負荷状態作るだけでも面倒そうだし
そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。googleで見つかった順ですが、 diversifEye [empirix.co.jp] とか WebLoad [quality-net.co.jp] とか Web Capacity Analysis Tool [microsoft.com] とか。
あと、この手の高負荷時のソフトウエアバグはOSに問題がある場合を除けばファイルや共有メモリなどの競合(race condition)に原因があるものなので、テンポラリファイルや名前付きイベントの名前の生成方法など、時間をキーにしている部分を重点的にチェックしていくとよいです。
Re:高負荷時の検証作業 (スコア:2, すばらしい洞察)
>ファイルや共有メモリなどの競合(race condition)に原因があるものなので、
>テンポラリファイルや名前付きイベントの名前の生成方法など、
>時間をキーにしている部分を重点的にチェックしていくとよいです。
そういった類の「思い込み」が、解決に1ヶ月以上もかかった遠因では?
Re:高負荷時の検証作業 (スコア:1, 興味深い)
画面表示まではちゃんと行くんだが、そこから印刷に行かせると、時々別ユーザの紙が出てくる…ログとかとっておいてもそれなりに動いているように見えるし…
ライブラリが怪しいから調査してくれと依頼しても、そんなことはないと突っぱねられるし…
Re:高負荷時の検証作業 (スコア:0)
Re:高負荷時の検証作業 (スコア:4, 参考になる)
が、顧客の稼働中のシステムはそのバージョンアップまでなんて到底待てないので…
当該のライブラリ(顧客が「これを使ってくれ」と指定してきた製品だった)がおかしい事を上記検証用コードと、ライブラリメーカーからの「対処します」覚書で理解してもらったうえで、印刷時のみ、という状況から、印刷時に当該のライブラリの処理をする場合だけシリアライズするように処理を変更することをご提案。処理がぶつかった場合、多少余計に時間がかかりますが、まぁ印刷処理(画面表示に比べるとはるかに長い時間がかかる)なのでということで、確実に処理できるようにコードを修正。また、ライブラリのバージョンアップがあった後には、それを入れるかどうか&この修正を戻すかどうかについては別途ご相談(費用が発生します)、ってことで最終的にはおちつきました。
…余談…
どうも、挙動を見た感じからすると、PDF作成時にライブラリの中で作るっぽい中間ファイルが、複数同時に走ると同じファイル名になってしまうケースがあったようで…これが一時ファイルで処理後にさくっと消されてしまうため証拠が残らず…かといって、ライブラリの中をリバースエンジニアリングして調べるわけにもいかず…現象を再現できる検証用コードを作るのに非常に苦慮しました…あのときはほんとに大変だったなぁ…
Re:高負荷時の検証作業 (スコア:1)
Re:高負荷時の検証作業 (スコア:1, 興味深い)
1.現象の再現 (要、高トラフィック環境)
2.不良と思われる箇所のソースチェック (ブラックボックス部(ライブラリ等)含まず)
3.ソースでは無さそうなのでブラックボックス部のメーカー調査依頼
4.メーカーから回答来るもはっきりせず、1.or 2.へ戻る
5.1~4の繰り返しで、やっとこさ該当箇所発見
6.メーカー提供の修正仮パッチ当てて再現テスト
7.修正できたと思われるのでメーカーと今後の対応打ち合わせ
8.修正を本パッチとしてメーカーリリース・サイト本修正
9.最終ランニングテスト
10.一般広報
まず1.の段階で時間がかなり掛かりそう。
下手すりゃ再現テストがWindowsではなく、再現しないLinuxで
メーカーがテストしていたとかの可能性も。(初歩的なミスの場合)
ただ、メーカーが絡んでも高負荷テストだと「調べてよ」と言っても
そう簡単にチェックが進むとは思いにくい。デバッガ使えそうに無いし。(←これ大きい)
Re:高負荷時の検証作業 (スコア:2, すばらしい洞察)
・顧客への報告書類作成
・再発防止策の策定と承認
・顧客立会いの下、再現及び同条件での修正後デモンストレーション
場合によってはシステムの総点検による別バグ出し&潰し
安全性・安定性の確保とサービスの早期再開とはトレードオフの関係になりますので、修正そのものよりも顧客承認(を得るに足る試験工数と報告書の作成)に時間がかかるものだと思います。
Re:高負荷時の検証作業 (スコア:0)
>
> そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。
有名どころでは LoadRunner [mercury.com] とか。(ただし高い)
Re:高負荷時の検証作業 (スコア:0)
(LoadRunnerほどじゃないけどこっちも高い)
この手のツールを使えば、シナリオさえ作成出来れば、
本件のような高負荷下でコンテンツ内容が異なる問題とかを
リリース前に検出出来てたのではと思う。