アカウント名:
パスワード:
トラフィック生成して高負荷状態作るだけでも面倒そうだし
そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。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, 興味深い)
画面表示まではちゃんと行くんだが、そこから印刷に行かせると、時々別ユーザの紙が出てくる…ログとかとっておいてもそれなりに動いているように見えるし…
ライブラリが怪しいから調査してくれと依頼しても、そんなことはないと突っぱねられるし…
Re:高負荷時の検証作業 (スコア:0)
Re:高負荷時の検証作業 (スコア:4, 参考になる)
が、顧客の稼働中のシステムはそのバージョンアップまでなんて到底待てないので…
当該のライブラリ(顧客が「これを使ってくれ」と指定してきた製品だった)がおかしい事を上記検証用コードと、ライブラリメーカーからの「対処します」覚書で理解してもらったうえで、印刷時のみ、という状況から、印刷時に当該のライブラリの処理をする場合だけシリアライズするように処理を変更することをご提案。処理がぶつかった場合、多少余計に時間がかかりますが、まぁ印刷処理(画面表示に比べるとはるかに長い時間がかかる)なのでということで、確実に処理できるようにコードを修正。また、ライブラリのバージョンアップがあった後には、それを入れるかどうか&この修正を戻すかどうかについては別途ご相談(費用が発生します)、ってことで最終的にはおちつきました。
…余談…
どうも、挙動を見た感じからすると、PDF作成時にライブラリの中で作るっぽい中間ファイルが、複数同時に走ると同じファイル名になってしまうケースがあったようで…これが一時ファイルで処理後にさくっと消されてしまうため証拠が残らず…かといって、ライブラリの中をリバースエンジニアリングして調べるわけにもいかず…現象を再現できる検証用コードを作るのに非常に苦慮しました…あのときはほんとに大変だったなぁ…