かなりの想像含みでいうならば、以下のようになるかとおもいます。
レスポンスの基本計算:
クライアント側インターフェイスプログラムの処理時間(上り+下り)
クライアント側OLTPの処理時間(上り+下り)
ネットワーク通過時間(上り+下り)
サーバ側OLTPの処理時間(上り+下り)
サーバ側DBMSの処理時間
の総和が基本的なレスポンス時間となる。
という感じでしょうか。
では、それぞれの処理時間を出すためには、それぞれの処理の仕様がどうであるかが分かる必要があると思います。
例えば、1処理が終わるまで後続処理を全てキューイングするような仕様であれば、1処理時間内に別の処理が入ってきた場合はそれが全て「多重」となり、レスポンス時間は「そのときのキュー数X1処理時間+処理中のものの残り時間」という計算式となります。
しかし、同時処理数分複数プロセスを立ち上げて並行処理するような仕様の場合、レスポンス時間は上記式では表せない者となります。(複数プロセスを稼動させることによるハードリソースの消費がレスポンスに影響を与えることになると思います)
従って、「多重度を出してからレスポンスを机上計算する」という方式よりも、
「全体処理のフローを要素に分け、その各要素での多重処理の仕様を明らかにした上で、机上計算に入る」というプロセスの方が妥当なきがします。
DBMSも、OLTPも、提供ベンダーから参考値がもらえると思います。
また、システム側ではないユーザ側のインプット作業としての多重度は、これまで手作業であったことから取得困難なんですよね。それならば、
1、ユーザの声を聞ききながら精緻化する
2、実際のユーザ作業を想像してパターンを作成し、ユーザに精緻化してもらう
といういづれかで実際の作業をもう少し具体的に把握したほうがよいかもしれません。
なんだか書いているうちにとりとめがなくなってきました。。。!
いかがでしょうか?
お礼
丁寧な回答有り難うございました。 なんとかユーザーと協力して頑張ってみます。