- - PR -
Strutsのデータソース
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2006-03-07 20:21
もしかしたら、分野が違うかもしれないんですが。
先日納品したWebシステムではStrutsを使っています。 データベースはOracleで、StrutsではDataSourceを利用しています。 Webシステムの要件として、最大同時接続数1000があるんですが、 これは、struts-config.xmlのDataSourceタグのmaxCountを1000にすればいいんでしょうか? 「Webシステム要件の最大同時接続数」とは「同時にOracleにアクセスできる最大数」のことなのかどうかが判断できずに困っています。 「同時にOracleにアクセスできる最大数」を1000に(maxCountも1000に)することは不可能ではないと思いますが、現実問題としてこんな設定をしてしまって良いんでしょうか? ちなみに、今のmaxCountは10です。 maxCountは10のままで、Webシステム要件の最大同時接続数:1000は実現可能でしょうか? 可能であれば、それをユーザに分かってもらうにはどう説明すれば良いでしょうか? | ||||
|
投稿日時: 2006-03-07 20:38
ウェブアプリケーションの設定で最大スレッド数の設定ができると思います。
これは、リクエストを受信してからレスポンスを送信するまでの流れが Javaのスレッドで実現されていますが、そのスレッドの最大数です。 スレッドの最大数を超えるリクエストが発生した場合、 どれかのスレッドがレスポンスを返し終えて処理可能な状態にならなければいけません。 それまでリクエストは待機することになります。 厳密な意味での同時処理数はサーバの最大スレッド数になりますので、 最大スレッド数が1000であれば、最大接続数も1000で構いませんが、 それより多い数は意味がありません。 逆にそれより少ない場合、例えば100のリクエストを受信して、 最大接続数が10であれば、90は待機することになります。 | ||||
|
投稿日時: 2006-03-07 21:57
横からちょっと補足しておきます。
HTTPの1リクエストの処理時間に対するDBが占める割合は、通常のシステムで あればそれほど高いわけではないのでもっと低い値を設定することが多いです。 Webの最大接続数=DBの最大接続数でも構わないとは思いますが、 最大1000のDBセッション数はそれなりなサーバでないと厳しいでしょう。 Oracleの場合、共有セッションでは1接続(プロセス)に対してPGAだけでも MB単位で使うことになるので、最低4〜8GBは積まないといけないはずです。 | ||||
|
投稿日時: 2006-03-07 22:17
ありがとうございます。
> Webの最大接続数=DBの最大接続数でも構わないとは思いますが、 そうなんですか・・・。 この質問をした背景には、Oracleの一時表領域の設定があります。 DBに数十万件(実運用で想定される最大件数)のデータを投入して性能試験を行ったところ、一時表領域がパンクしたので、SQLの見直しをさせられました。 SQLを修正して、自社の環境(本番環境よりはスペックは劣る)で試したところ、 一時表領域の拡張が400MBで収まりました。 並列で動かさせることを考慮すると、10(maxCount)x400MB=4000MB となり、 一時表領域は5GBあれば問題ないとユーザに回答してしまったんです。 最大接続数を1000にすると、1000x400MB=400000MB となり、500GBも必要となってしまいます。 せっかく修正したSQLもあまり修正の余地がありませんし、修正したとしても100分の1の結果が得られるとは思えません。 性能が悪いという話ならまだしも一時表領域が足りないというのでは、SQLのみが修正ターゲットになって・・・。 >最低4〜8GBは積まないといけないはずです。 これに関しては10GB弱くらいまでならOKみたいです。 | ||||
|
投稿日時: 2006-03-07 23:27
最大接続数とその処理を同時に行うユーザー数はイコールではないと思いますけど。 システム的に重い処理(例えば月次の請求計算など)を行う人数はそれほど多くない のではないですか?というか、普通は少ないはずです。時間のずれもありますし。 それだけのシステムであれば、表量域の5GBなんて誤差だと思いますから、 「計算上は5GB程度ですが、DB全体で使用する作業領域なので不測の事態に 備えて10GB確保しておきました。その処理は同時に10人も走らせないですよね?」 というような感じにしてしまっても差し支えないような気もします。 それでダメと言われるようなお客さんの場合は、システム側で同時処理数を 制限するように修正しないといけないでしょうね。。。 | ||||
|
投稿日時: 2006-03-07 23:40
同時接続数といっても、お客さんがどのような認識で言っているのかが
一番の問題だと思いますよ。 エンドユーザの方だとセッション数と同時接続数を 勘違いされている方もいらっしゃいますし、 同時接続数がトランザクション数を示すのか セッション数を示すのか確認してみてはいかがですか? | ||||
|
投稿日時: 2006-03-08 00:15
どうもです。 >あしゅさん 一時表領域がパンクしたのは、更新処理のときではなく検索画面で検索をしたときなんです。 それでも↑のような対応でも良いんでしょうか? >かつのりさん >エンドユーザの方だとセッション数と同時接続数を >勘違いされている方もいらっしゃいますし、 >同時接続数がトランザクション数を示すのか >セッション数を示すのか確認してみてはいかがですか? エンドユーザではないですし、一時表領域がパンクしたときの状況を知っています。 前述しているように更新処理ではないんですよ。 1000人同時にselect実行を可能にすることが要求のように思えるんですが・・・。 | ||||
|
投稿日時: 2006-03-08 00:29
補足します。
SQLの修正とこちらの見解(10x400MB=4000MBで一時表領域は5GBあれば問題ない)を報告したところ、同時接続数は1000のはずとの突込みが入ったんです。 ということで、やはり400MBでは多いと言いたいのではないかと思うんです。 |