- - PR -
基になる接続が閉じられました
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-08-18 09:18
挑戦の前に、ちょっと考えてください。 今作っているのは、Webアプリですよね。Webアプリというのは、どのようなものですか？HTML上に配置されたFORMを、サーバ上のアプリケーションに投げて、アプリケーションの結果をHTMLに載せて返しますよね。 では、HTMLを投げたり、返されたHTMLを処理するのは誰ですか？クライアントのブラウザですね。 それでは、ブラウザというのは、どのようなものですか？サーバにある情報を、見やすい形で表示するものですね。誰に？そう、ここに人が介在するのです。 では、その人は、９０分も終了を待っていられますか？もちろん、他の作業をしながらなら、待っていられるでしょう。しかし、その作業の終了を待っているだけ、なんてことはできないですよね。つまり、Webアプリケーションというのは、人間がその作業の完了をただ待つだけの状態でいられることができる時間以内に結果を出すべきなのです。その時間以内に完了できないなら、他の形態にするべきです。 また、２千〜１万件のデータをどのような形で表示させますか？２千から１万の、画面上に表示されたデータなんて、誰がみたいと思いますか？もちろん、ファイルに出力して、プリントアウトしたりするというなら、話は別です。表示するにしても、１００件程度単位に分けて出すというなら、そういうのもありでしょう。 私には、卍さん（の作られているシステムの仕様）は、人間の限界にチャレンジしているように思えます。 | ||||||||
|
投稿日時: 2004-08-18 14:57
ありがとうございます。Jittaさん。
まさにその通りでございます。顧客本位、ユーザ思考の立場にたって システムを構築するという根本を忘れておりました。 小生な私に、原点を思い出しさしていただき本当に感謝いたします。 しかし、既に挑戦してしまったため結果を報告いたしますと MachineConfigのSeesionStateやexecutionTimeoutの値を増やしましたが やはり、接続が切断されてしまいました。 もう一度構造を見直し、処理速度自体をあげることに挑戦したいと思います。 ちなみに C#での構築で（夜間バッチ処理）なのですが、C#自体、またはドットNET自体の 処理が遅いとの声もあるようですが、なにかお心あたりがございましたらどうか よろしくお願いいたします。 | ||||||||
|
投稿日時: 2004-08-18 15:22
それは、IL形式だから、という意味でしょうか。「.NET Frameworkの概要」には、このように書かれています。
私は、「実行前（ユーザにとっては実行を指示した瞬間）にJITコンパイルされ、ネイティブコードで実行される」と理解しています。よって、起動時間は多少遅くなりますが、起動後はネイティブと同等である、と。（違っていれば、補足願います） それでも不安なら、ネイティブコードに変換するツールがあります（ILASM.exe）。 私は、定時に実行したい、ユーザとの対話が必要ないプログラムは、Windows Serviceとして実装しました。１日１回しか動かないので、サービスにするのはとてももったいないのですが、「定時」をプログラム中で制御できるので。 「スケジュールされたタスク」で実行するようにすれば、コンソールアプリケーションとして実装し、ユーザが自由に実行時間を設定できます。 | ||||||||
|
投稿日時: 2004-08-19 01:52
夜間バッチ処理にC#を使わないほうがいいという意見についてはコメントが出来ます。
夜間バッチ処理は一般に画面にデータを表示しなくていいサーバーのデータが更新されればいいという特徴があります。 たとえばSQLサーバー内部で処理できればクライアントとの通信は発生せず、またSQLサーバーの最適化された環境での処理ということもあり早いのです。 したがって.NetやC#にかかわらず夜間バッチ処理はデータベースの持っているストアドプロシージャ等の機能を使ったほうがいいという話です。 _________________ えムナウ Microsoft MVP for Visual Developer - C#,2005/01-2007/12 えムナウのプログラミングのページ Blog1 Blog2 | ||||||||
|
投稿日時: 2004-08-19 08:20
う〜ん、確かに、「まとまったデータを消す」という処理を、ストアドプロシージャに任せるのは賛成ですが、ストアドプロシージャであっても、DELETE文を１ラウンドトリップで実行できるように設計しても、その処理自体に時間がかかるようだとNGですよね。 今回の件では、「ファイルを戻す必要があるのか」というところが問題だと思います。Webサービスというのは、様々なPCからアクセス可能です。また、行いたい処理は夜間の不要データ削除処理と思われますが、Webサービスにアクセスすることでその処理が動作してしまうのは、データ保全上の問題がないでしょうか。 私は、この処理は、サーバ内で閉じるべきと思います。ファイルの性質にもよりますが、ログ程度の意味しか持たないファイルであれば、日付などで判別可能なファイル名にして、共有ディレクトリに吐き出せばよい、それを参照するようにすればよい、と考えます。 | ||||||||
|
投稿日時: 2004-08-19 10:18
エムナウさん Jittaさん ご意見ありがとうございます。
まずエムナウさんの意見ですが 「したがって.NetやC#にかかわらず夜間バッチ処理はデータベースの持っているストアドプロシージャ等の機能を使ったほうがいいという話です」 まことにその通りでございまして、現在、処理の遅い部分の場所を調査中で それがアプリケーションサーバとデータベースサーバ部分での処理速度の問題 であれば、ストアド化も検討中であります。 ところが、その他の要素として、Updateのタイミング問題、C＃ロジックの問題も ありそうな雰囲気です。 次にJittaさんのご意見ですが 「「ファイルを戻す必要があるのか」というところが問題だと思います。」 「また、行いたい処理は夜間の不要データ削除処理と思われますが、Webサービスにアクセスすることでその処理が動作してしまうのは、データ保全上の問題がないでしょうか」 「私は、この処理は、サーバ内で閉じるべきと思います」 エクセレント。私もまさに、そう感じておりました。 WEBサービスにする必要があるのかと。 しかし、DBサーバが業務別に複数台存在し、DBへのアクセスは、さまざまな場所から 行われる処理なのです。さらに不要データ削除処理のみでなく、更新、追加等も行われます。 データ保全上等、セキュリティの問題は、とても心配でございます。 そして | ||||||||
|
投稿日時: 2004-08-19 10:22
エムナウさん Jittaさん ご意見ありがとうございます。
まずエムナウさんの意見ですが 「したがって.NetやC#にかかわらず夜間バッチ処理はデータベースの持っているストアドプロシージャ等の機能を使ったほうがいいという話です」 まことにその通りでございまして、現在、処理の遅い部分の場所を調査中で それがアプリケーションサーバとデータベースサーバ部分での処理速度の問題 であれば、ストアド化も検討中であります。 ところが、その他の要素として、Updateのタイミング問題、C＃ロジックの問題も ありそうな雰囲気です。 次にJittaさんのご意見ですが 「「ファイルを戻す必要があるのか」というところが問題だと思います。」 「また、行いたい処理は夜間の不要データ削除処理と思われますが、Webサービスにアクセスすることでその処理が動作してしまうのは、データ保全上の問題がないでしょうか」 「私は、この処理は、サーバ内で閉じるべきと思います」 エクセレント。私もまさに、そう感じておりました。 WEBサービスにする必要があるのかと。 しかし、DBサーバが業務別に複数台存在し、DBへのアクセスは、さまざまな場所から 行われる処理なのです。さらに不要データ削除処理のみでなく、更新、追加等も行われます。 データ保全上等、セキュリティの問題は、とても心配でございます。 そして | ||||||||
|
投稿日時: 2004-08-19 10:28
そして、やはり何よりも問題は
現在2000件〜1万件で、90分（ファイル量にして2〜3MB）は ロジックの変更により処理速度を早めれば、このオーダはクリアできるのですが 100万件〜1000万件とスケールがあがると、どちらにしろ ロジックの変更による対応では、限界があり、「90分」という 時間がかかってしまいます。 そうした場合、WEBサービスを接続しつづける（強制的に切断されない）設定が 必要になるのです。 まだ手を加えていない、設定として OLEDBの接続プーリング時間 ポート自体の設定 など ハード面、レジストリィ部分が考えられますが そのあたりのお心当たり等、なんでもかまいませんので、ご意見、ご感想があれば どうぞよろしくお願いします。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。