refreshを使用しているのですね。refreshで問題なく稼動するかテストしたいと思います。計算もしていただきありがとうござます。6秒間隔で延々とリクエストされ続ける、というのはかなり負荷が高くなりますよね。HTTP/TCPの設計思想からいっても、6秒の更新間隔を要求するのはぎりぎりです。転送量にもよりますが、1日ずっとなら、DoSと間違われてもおかしくないくらいかと。#すみませんが、本当に入っているのかは知りません。細かいフィルタが一杯はいってることしかわかりません。今後HTTPの途中に、1日ずっと続くようなリクエストを止めるフィルタが入ってもおかしくありません。この関連でIIS6が何か制御しているか調査してみます。調査結果はまたこのトピックにご連絡いたします。転送回数も上記の様に1日で14400になります。#むしろ頑張ってる方かも。ブラウザにも問題があるか調査してみます。ちなみにブラウザはFireFox3.5です。設計に無理があると思います。本当に6秒更新とASP.Netが必要なのか検証したほうがよいかと。秒数を多少伸ばすのは可能なのですが、ASP.netを変更するのは難しいです。お客様環境で稼動しているものなので。Ajax系の動的更新を使うとか。#Ajaxも連続稼働に耐えるかちょっと微妙ですが。プログラムを作成する時間に限りがございますので。※ご丁寧にはつねさん、かたぎりさんの返信にも答えて頂きありがとうございました。更新するかどうか、その時刻はクライアントがスクリプトとして持っています。セッションは関係ないかと思います。あれ?ワーカープロセスを無効にしたからセッションがのこっているんですよね?私が言いたかったことは、ワーカープロセスのリサイクルが発生してもセッションを残すのであれば、InProcではなくSessionStateServerの方が適切じゃないかということです。sessionStateのタイムアウト値ってどれくらいにしているのでしょうか?sessionStateのタイムアウト値はデフォルトのままなので、20分です。Session情報は、6秒おきに行う処理の中で毎回しております。10:14:19)セッションの話は、今回のタイマの話とは関係ないでしょうが、まあ別途重要な話ではあります。何らかの理由でワーカープロセスが再起動してしまえば、やっぱり同様に困ったことになるはずですから。再起動を完全に防ぐことはまず不可能です。問題が起こりにくい更新方法を模索するしか無いでしょう。※ブラウザを使うならMETA使う方が、シンプルな分まだ耐えるかも知れません。そもそも論を言うなら、出来合いのブラウザで長期間自動更新させるのは無茶です。何かの拍子にネットワークの調子が悪くなったとか、たまたまサーバ処理で何らかの事情でエラーが起こったとか、とにかくたまたま運悪く何かあれば一発で停止です。専用クライアントでも作るか、ブラウザや通信の状況を監視して再起動してやる位のことをしないと、まず確実に動かし続けることは無理でしょう。専用クライアントであっても別途監視なりの仕組みが必要なくらいです。今度はスクリプトの信頼性の方が問題になるでしょう。15:43:30)なちゃさん、はつねさん、かたぎりさん、れいさんご連絡が遅くなり申し訳ございません。timerが止まる原因が判りましたのでご連絡致します。原因は、WebDbサーバーの負荷が高くなった為、クライアントからのTimer処理が受け付けられなくなったようです。現在、WebサーバとDBサーバを1つのサーバに入れて運用しています。あるサーバからは、データの書き込み、クライアントからはデータの参照を行っています。10画面から6秒周期で1日アクセスされっぱなしだった為、WebDBサーバのPF量(メモリ使用量)がパンパンに膨らみ、クライアントの処理を受けれなくなったようです。対策としては、リフレッシュ周期を伸ばす&アプリケーションのメモリリーク対応を行う&夜間に1度ワーカープロセスを起動&バッチで新画面を呼び出すなどを考えております。IIS6の機能でアタックのようなプロセスを自動で切断する機能があるか調べてみましたが調べた限りでは見つけることが出来ませんでした。念のため情報共有です。お忙しい所、色々とご協力いただきどうもありがとうございました。バーチャルな世界ですが、皆さんの温かい返信をいただき、本当に感謝しております。今後も何かございましたら、どうぞよろしくお願い致します。15:44:51)すみません、解決済みにチェックを入れておりませんでした。皆様、どうもありがとうございました。現在、WebサーバとDBサーバを1つのサーバに入れて運用しています。データの参照を行っています。膨らみ、クライアントの処理を受けれなくなったようです。※ワーカープロセスというものがある事を知り、IIS6.0のワーカープロセスは下記手順により無効にしています。こんなことしてるからだよ...(^-^;)解決方法は、セッションの持ち方を変える事です。セッション内容が消えた時点で、もっと調査の手を広げるべきでしたね。返信>>※ワーカープロセスというものがある事を知り、IIS6.0のワーカープロセスは下記手順により無効にしています。解決方法は、セッションの持ち方を変える事です。セッション内容が消えた時点で、もっと調査の手を広げるべきでしたね。ワーカープロセスの無効化ではなくてそれの時間によるリサイクル(再起動)の無効化ですよ>まことさんというのはさておき、そうですか?ワーカープロセスのリサイクルは一種の対症療法であって、問題の原因ではありません。リサイクルの設定もいつかあって、今回のに引っかかるとしたらむしろメモリ上限系の設定でしょうし。全部無効にしてるのなら別ですが。セッションの持ち方を変えるのも、望ましい方向ではありますが、これも今回の件に関しては解決方法というより、対症療法のために必要だというだけです。実運用上それで回るようになるならそれは有効な対策ではありますが。夜間に1度ワーカープロセスを再起動するまえに症状がでないようにした方がいい気がします。リフレッシュは使っていないところに対して行うので、バッチで新画面を呼び出すみたいなことも不要ですし、なんだか大変な対応しているように思えてしまいます。あと、できるかどうか確認していないけど処理負荷が高いってことであれば、タイマーイベントが発生したらタイマーを止めて処理後にタイマー起動とすることで、6秒間隔ではなく処理と処理の間が6秒開くことになるので状況は違くなるように思います。質問者が解決済みとしているので解決済みチェック復活しておきますね。