- - PR -
Sessionのタイムアウトの影響順序について
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-08-29 17:58
皆様初めまして。いつもここで色々な疑問を解決させていただいております。
今回、Sessionのタイムアウトの影響順序について質問させて頂きます。 Googleで、IIS、machine.config、web.configといった単語で検索してみたところ、 下記のサイトを見つけることが出来ました。 http://studiodragoonnet.main.jp/programming/tips/ASPNET/timeout.html 上記ページには、数字が大きいほうが優先順位が高くなるという記述がありました。
下の方に行く程優先順位が高くなるとの事で、 確かに、1つのサーバ上で稼動する各Webアプリケーションで 用件によって細かなセッションタイムアウトの指定が出来るというのには 当然そうなっているだろうという事が予想できます。 例) 1.で60分に設定 2.で30分に設定 (結果)30分でSessionが切れる ただ、疑問なのが「2のIIS」で20分と指定していたものを 「4のweb.config」で1時間とした場合、4が優先されてしまうのかという点です。 これでは、サーバ上で稼動しているWebアプリ1つによって、 サーバ全体に悪影響を与えてしまう場合があるのではないかと思うのですが、 いかがなものでしょうか。 個人的に、優先順位は1→5で高くなるが、それは、数値が小さい方が Sessionタイムアウトが長い場合ではないかと思っていたのですが、 そういった情報については見つけることが出来ませんでした。 ご存知の方がいらっしゃいましたらご教授下さい。 宜しくお願い致します。 | ||||||||
|
投稿日時: 2004-08-29 21:39
それぞれの、影響範囲を考えてみれば、どうですか?下、優先順位が高いほど、影響範囲が小さくなりますよね。 っていうか、まさか、それぞれの「影響範囲」がわかりません、ということでしょうか? | ||||||||
|
投稿日時: 2004-08-30 01:54
Jitta様
ご返事ありがとうございます。 それぞれの影響範囲については以下のような認識です。 間違っていた場合、ご指摘をお願い致します。
ただ、一つのWebアプリの処理が、 サーバー全体に負荷をかけるという事もありますし、 Sessionはサーバ上のメモリを消費するものですので 「小さい影響範囲の設定」がサーバ全体に 悪影響を与えてしまえるのかな?と思った次第です。 普通に考えて、サーバ全体の設定によって作られたルールが、 各アプリケーションによって簡単に破られてしまう事はないと思っていますが (上位で決められたルール範囲内で自由な設定は当然出来るわけですが)、 ASP.NETについてまだまだ理解しきっているわけでもありませんので これだ!というような情報を見つけたいと思いまして。 宜しくお願い致します。 [ メッセージ編集済み 編集者: takeyan 編集日時 2004-08-30 01:56 ] | ||||||||
|
投稿日時: 2004-08-30 09:27
あ、済みません、質問の意図を取り違えていたようです。「1つのWebアプリケーションが、全体に影響を与えるのか」という方ですね。「1つのWebアプリケーションの設定が、全体に適用されるのか」と読み違えていました。
例えば、セッションをインプロセスにせず、SQL Serverやステートサーバを使うと、「サーバのメモリ」は消費しませんよね。 実行されているアプリケーションの関係を調整するのは、アプリケーションサーバの問題で、書くアプリケーションが気にする(いや、開発者は気にしながら設計/製造するべきでしょうけど)ことではないですよね。アプリケーションサーバは、実際にかかっている負荷を見ながら、処理を振り分けるでしょう。
反対に、「一つ一つで設定されていなければ、これ」、デフォルトが定義されているとも考えられます。例えば、あるアプリケーションは・・・そうですね、実際的な例を出しましょう。 私が昨年度関わっていたシステムは、システムのテスト工程を支援します。テスト項目がDBに登録されており、ユーザは画面上に一覧表示された項目を、実際に行って、良否を登録します。このとき、システム全体で「セッション持続時間は10分」と決められていたとしましょう。しかし、テスト項目の実行に、どれくらい時間がかかるのか、それはわかりません。システムがソフトウェアであれば、一瞬で終わるものが多いでしょう。しかし、「印刷のテスト」や「夜間バッチのテスト」では、長時間かかることもあるでしょう。それらが10分以内に終わらなければ、セッションが切れ、ログイン画面からやり直しです。また、画面上に表示され、チェックしていた他の項目について、画面上の情報が失われます。 このため、この画面…というか、この機能についてはセッション時間を延長しています。こういう“例外”の設定ができる、と考えてみると、必要ではないでしょうか。 #実際には「項目を紙に出して、後から一括登録」という使い方が多いのだが、 #「ペーパーレス」が目標なので・・・ | ||||||||
|
投稿日時: 2004-08-30 10:14
はにまるです。当スレッドの直接回答ではありません。
階層毎(OS>アプリ>個別プロジェクト>個別処理)に同一の設定内容を 指定出来る考えは、多くのアプリケーションやツールにて存在致し この際の考えとして「権限設定方式」と「初期値設定方式」があります。 ※尚、両語は造語なのでご注意を。 権限設定方式とは、 下位層(OSやアプリの設定)範囲内であれば上位層が個別設定出来る、下位層優先 の方式です。例えば、営業部の担当者Aは営業部の役割範囲を超えては行けません。 # 営業部が下位層、担当者Aが上位層 初期値設定方式とは、 本来、個別設定が前提だが面倒なので全体の初期値設定(変更可)が出来る上位層優先の 方式です。例えば転職の際、年齢による給与設定が存在するが、特定経験者は 優遇(別途考慮)する考えですね。 # 年齢別給与が下位層、経験者優遇が上位層 上記2つの発生理由は大きく違い、 権限設定方式が、管理手段(プロセス)から設計されているのに比べ、 初期値設定方式は、操作性から考慮されている訳です。 利用者から見れば、 権限設定方式が、全階層にて矛盾性のない整合性を必要とする設定 初期値設定方式は、整合性を必要としない設定 位のレベルで考えても宜しいかと思います。 私は、当スレッドの技術的な事は判りませんが、 sessionの接続時間は、今後の運用次第で変わるモノでしょうし、 WEBであれば尚更、動的な設定が必要とされるでしょうから、 接続時間は、個別設定を前提として、初期値設定方式で個別指定の煩わしさを 軽減するという考えが妥当かな?と素人目で思います。 尚、権限設定方式は、名の通りまさしく権限設定以外(直接的な資源分配含む)では お目に掛かりません。(って造語ですが...) 以上、設計者の目から語って見ました。 | ||||||||
|
投稿日時: 2004-09-09 03:01
Jitta様、はにまる様、ご回答ありがとうございます。
また、確認が遅くなりまして大変申し訳ございません。 先週から特に忙しくなってしまい、平均睡眠時間が 3時間を割っているような状況になってしまいまして。 意外に自分は丈夫だったんだなぁと思う今日この頃(…略) Jitta様への返信********************************* > 例えば、セッションをインプロセスにせず、SQL Serverやステートサーバを使うと、 >「サーバのメモリ」は消費しませんよね。 > 実行されているアプリケーションの関係を調整するのは、アプリケーションサーバの > 問題で、書くアプリケーションが気にする(いや、開発者は気にしながら設計/製造 > するべきでしょうけど)ことではないですよね。アプリケーションサーバは、 > 実際にかかっている負荷を見ながら、処理を振り分けるでしょう。 仰るとおり、SQL Serverやステートサーバを利用すれば、 根本的にWebサーバのメモリ使用を軽減する大きな対処法になるのでしょうね。 パフォーマンス何かも見ながら、お客さんにデータで提示出来るといいですね。 今の仕事が一段落して、正常動作の保証フェーズからパフォーマンスアップの フェーズに移行したら試してみたいと思います。 > 反対に、「一つ一つで設定されていなければ、これ」、デフォルトが > 定義されているとも考えられます。例えば、あるアプリケーションは・・・ > そうですね、実際的な例を出しましょう。 > 私が昨年度関わっていたシステムは、システムのテスト工程を支援します。 > テスト項目がDBに登録されており、ユーザは画面上に一覧表示された項目を、実際に > 行って、良否を登録します。このとき、システム全体で「セッション持続時間は10分」 > と決められていたとしましょう。しかし、テスト項目の実行に、どれくらい時間が > かかるのか、それはわかりません。システムがソフトウェアであれば、一瞬で終わる > ものが多いでしょう。しかし、「印刷のテスト」や「夜間バッチのテスト」では、 > 長時間かかることもあるでしょう。それらが10分以内に終わらなければ、セッション > が切れ、ログイン画面からやり直しです。また、画面上に表示され、チェックして > いた他の項目について、画面上の情報が失われます。 > このため、この画面…というか、この機能についてはセッション時間を延長しています。 > こういう“例外”の設定ができる、と考えてみると、必要ではないでしょうか。 > #実際には「項目を紙に出して、後から一括登録」という使い方が多いのだが、 > #「ペーパーレス」が目標なので・・・ 大変わかりやすい例、ありがとうございます。 アプリケーションの設定によって、全体的な設定に例外を作る事が 出来るというイメージになるのですね。 確かに、そのような作りの方が、少数の例外のために、 システム全体のセッションタイムアウトを必要以上に長く指定するといった事をせず、 個別の対応で全体に影響を設定の面で与えずに済むわけですね。 そういう視点が欠けていました。勉強させて頂き、ありがとうございます。 はにまる様へのご返信******************************* > 上記2つの発生理由は大きく違い、 > 権限設定方式が、管理手段(プロセス)から設計されているのに比べ、 > 初期値設定方式は、操作性から考慮されている訳です。 > 利用者から見れば、 > 権限設定方式が、全階層にて矛盾性のない整合性を必要とする設定 > 初期値設定方式は、整合性を必要としない設定 > 位のレベルで考えても宜しいかと思います。 > 私は、当スレッドの技術的な事は判りませんが、 > sessionの接続時間は、今後の運用次第で変わるモノでしょうし、 > WEBであれば尚更、動的な設定が必要とされるでしょうから、 > 接続時間は、個別設定を前提として、初期値設定方式で個別指定の煩わしさを > 軽減するという考えが妥当かな?と素人目で思います。 権限設定方式と、初期設定方式、造語だという事でしたが、 イメージをつかみつつバッチリ理解できました! サーバの管理・メンテナンスという観点から、 私はNTFSのアクセス権なんかのイメージで考えてしまい 権限設定方式で考えてしまっていたのですが、 確かにWebシステムというある意味で多分に流動的なものを 含むシステムとしては、より自由度の高さを保持した 初期値設定方式の方が将来的な運用を考えた際に便利なんでしょうね。 とても勉強になりました。 私も皆様のように深い知識を身につけ、設計者の視点で考察出来るよう 日々勉強して参りますので、今後とも宜しくお願い致します。 ご返信ありがとうございました。 |
1