- - PR -
処理時間のかかるリモートオブジェクトのメソッドを呼び出すとエラーになるのですが
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-09-27 22:35
私は、httpRuntimeのexecutionTimeoutの値と応答性には関連があるとは 認識しておりませんし、また、アッキーさんと同様にクライアントの実装や リモートメソッドの実装に関して言及していませんので、上記の発言の意 図するところが思い当たりません。 私の認識に誤り・不足があればご指摘下さい。 | ||||
|
投稿日時: 2004-09-27 23:01
「webへの書き込み禁止」なところにいるので、日中は読めますが、書き込みできません。夜、早朝は、妻に「書き込み数が2位以下になるまで禁止」と言われているので(^^;、妻の目を盗んでのアクセスとなります。遅いアクセスはご容赦ください。
#っつうか、元々Webのコミュニケーションって、そういうものだし・・・ どのような物であるか書いていないですから、どのようにも解釈できるわけですよね。私は、リッチクライアントを想像しました。 また、たとえば夜間バッチ処理であったとしても、そこには「夜間」に終わらせなければならないという制限があります。時間を決めてメンテナンス時間をもうけ、その間に行う処理かもしれませんが、それにしても「メンテナンス時間」という制限があります。どのような機能であれ、「無限にある時間を無限に使える」わけではない、と思います。 また、使う側はいい加減(作る側からすると)なもので、「1時間ぐらいならいいよ」といいながら、実際に1時間待たせると「遅い」と言います。 知り合いのオペレータが体験したことですが、夜間メンテの直前にホストが異常停止し、復旧したのはメンテ終了時間の30分ほど前だった、ということがあったそうです。通常のバックアップでは全然時間が足りないので、その人は緊急度の高いデータのみバックアップし、その他のデータは優先度を低くしたプロセスで、実務中に行ったそうです。このように、いつ、何が発生するか分からないので、「1時間あるから、50分くらいかかってもいいや」というような設計は危険です。もちろん、「作った当初は2時間かかっていたけれど、何とか50分で終わるようにチューニングできた」というのは別です。 私の「その辺の設計を見直す必要があるんじゃない?」というのは、「3分もらっているから、3分以内に終わればいいや」という安易な考えで設計しているなら、それを見直せ、ということです。3分以内に終わればいいやではなく、可能な限り早く終わるように設計(チューニング)するべき、ということです。データ量に左右されるような処理であるならなおさらです。その辺、何も書いていないので、クリティカルな方で考えています。 | ||||
|
投稿日時: 2004-09-28 01:16
なるほどです。
やはり、実務では様々な視点でみて「適切である」ということを決定するのですね。 大変参考になりました。 というか、こんなにも考えなくてはいけないことがあるのかと、 感心しました。 |