アカウント名:
パスワード:
トラフィック生成して高負荷状態作るだけでも面倒そうだし
そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。googleで見つかった順ですが、 diversifEye [empirix.co.jp] とか WebLoad [quality-net.co.jp] とか Web Capacity Analysis Tool [microsoft.com] とか。
あと、この手の高負荷時のソフトウエアバグはOSに問
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
高負荷時の検証作業 (スコア:2, 興味深い)
トラフィック生成して高負荷状態作るだけでも面倒そうだし、
単純負荷じゃ駄目っぽいし。
Re:高負荷時の検証作業 (スコア:5, 参考になる)
トラフィック生成して高負荷状態作るだけでも面倒そうだし
そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。googleで見つかった順ですが、 diversifEye [empirix.co.jp] とか WebLoad [quality-net.co.jp] とか Web Capacity Analysis Tool [microsoft.com] とか。
あと、この手の高負荷時のソフトウエアバグはOSに問
Re:高負荷時の検証作業 (スコア:1, 興味深い)
1.現象の再現 (要、高トラフィック環境)
2.不良と思われる箇所のソースチェック (ブラックボックス部(ライブラリ等)含まず)
3.ソースでは無さそうなのでブラックボックス部のメーカー調査依頼
4.メーカーから回答来るもはっきりせず、1.or 2.へ戻る
5.1~4の繰り返しで、やっとこさ該当箇所発見
6.メーカー提供の修正仮パッチ当てて再現テスト
7.修正できたと思われるのでメーカーと今後の対応打ち合わせ
8.修正を本パッチとしてメーカーリリース・サイト本修正
9.最終ランニングテスト
10.一般広報
まず1.の段階で時間がかなり掛かりそう。
下手すりゃ再現テストがWindowsではなく、再現しないLinuxで
メーカーがテストしていたとかの可能性も。(初歩的なミスの場合)
ただ、メーカーが絡んでも高負荷テストだと「調べてよ」と言っても
そう簡単にチェックが進むとは思いにくい。デバッガ使えそうに無いし。(←これ大きい)
Re:高負荷時の検証作業 (スコア:2, すばらしい洞察)
・顧客への報告書類作成
・再発防止策の策定と承認
・顧客立会いの下、再現及び同条件での修正後デモンストレーション
場合によってはシステムの総点検による別バグ出し&潰し
安全性・安定性の確保とサービスの早期再開とはトレードオフの関係になりますので、修正そのものよりも顧客承認(を得るに足る試験工数と報告書の作成)に時間がかかるものだと思います。