現場に入ってサービス開始済みのシステムで問題多発中。
もう歳末大売出し状態ですな。
気配はあったんだが、ここに来て無理が効かなくなったというか。
アクティブな機能とパッシブな機能があるんですが、パッシブな部分の性能条件をはるかに超える運用がされていたんですよ。条件数値のおよそ150倍~190倍。
内々には、負荷試験の結果、受信系の影響は能動系に影響出ないだろうと踏んでたんですが、甘かった。
DBアクセスの際にどうしても検索が総レコード数の影響を受けるわけで、秒間数十トランザクションが背景負荷で掛かってるとボトルネックが生じてしまう。
惜しむらくは、そこまで性能条件に組み込まなかったために、素直なDBアクセスで実装しちゃってたんだよなあ。
イベントは一旦メモリに置いて、まとめ処理することでクエリの回数を極力減らすとか、後からだったらなんぼでも知恵が回るんだけど、所詮後知恵。
しかも、残っているけど使わないはずの機能なので、問処切ってもらっても公式に対応はできませんとしか言えない範囲だったりするわけで。
まあ、あくまでもバックヤードのシステムなので、お客様に直接迷惑かけないだけマシか。
[教訓] 要求条件がはっきり出てこないマス向けシステムの場合、最初に想定した性能条件の200倍を条件に設定しよう。できるかそんなの(#ノ゜皿゜)ノ
もう歳末大売出し状態ですな。
気配はあったんだが、ここに来て無理が効かなくなったというか。
アクティブな機能とパッシブな機能があるんですが、パッシブな部分の性能条件をはるかに超える運用がされていたんですよ。条件数値のおよそ150倍~190倍。
内々には、負荷試験の結果、受信系の影響は能動系に影響出ないだろうと踏んでたんですが、甘かった。
DBアクセスの際にどうしても検索が総レコード数の影響を受けるわけで、秒間数十トランザクションが背景負荷で掛かってるとボトルネックが生じてしまう。
惜しむらくは、そこまで性能条件に組み込まなかったために、素直なDBアクセスで実装しちゃってたんだよなあ。
イベントは一旦メモリに置いて、まとめ処理することでクエリの回数を極力減らすとか、後からだったらなんぼでも知恵が回るんだけど、所詮後知恵。
しかも、残っているけど使わないはずの機能なので、問処切ってもらっても公式に対応はできませんとしか言えない範囲だったりするわけで。
まあ、あくまでもバックヤードのシステムなので、お客様に直接迷惑かけないだけマシか。
[教訓] 要求条件がはっきり出てこないマス向けシステムの場合、最初に想定した性能条件の200倍を条件に設定しよう。できるかそんなの(#ノ゜皿゜)ノ