サーバ側の処理は多すぎないのか？

質問

◆多くのイベントを取りすぎてしまったら待ちが発生したりしないのでしょうか？
(runat=server、with event と記載して、多くのイベントをハンドルしているとき)

◆例　⇒　グリッドコントロールの内の各コントロールのフォーカスアウトとかのイベントを取るなど。
通信の回数も多くなるでしょうし、些細な操作でrequestに対するresponse を待っていたら、
待ちが発生するのでは？と思っていました。
しかし、フォーカスアウトとまではいかないまでも、結構たくさんのイベントを取っているシステムを見かけることも多いです。
(通信速度は、私が思っているよりも全然早いものなのでしょうか？意識する必要がない？でも通信の調子が悪いときだってありますよね？)

◆サーバー側に負担は掛けないようにした方が良い？
JQueryで処理できることは、極力JQueryで処理した方が良いのでしょうか？
みなさんはどう判断していますか？

回答No.1

onos · ベストアンサー

>◆多くのイベントを取りすぎてしまったら待ちが発生したりしないのでしょうか？

runat=server からASP.NETだと推測しての回答ですが。
ASP.NETでのイベントはフレームワークが一定の順序でみつけだして特定のタイミングで発生します。
多くのイベントで長い処理を実装していればそれだけ時間がかかる、ということはあると思います。

ここでいっている「待ち」の意味がわかりません。

たとえば書くコントロールのフォーカスアウトといってますけど、、、これはオートポストバックを行うようにしていたらそのたびにリクエストがはしりますが。。。
ほんとにそんなにたくさんリクエストはしるような処理にしているシステムがありますか？

サーバ内の処理としてイベントが多く記述されている「だけ」なら、一度のリクエストで最初に書いたように決まった順番でイベントがはしります。
これならリクエストが繰り返されるわけではないので、数が多く記述されていてもなんの問題もないはず。

ブラウザとサーバの間でリクエストがはしる、という場合と、サーバの処理のなかで「イベント」が発生する場合とはまったく別のものですけど、もしかしてその区別が着いてないんじゃないですか？
よく考えてみてください。

> ◆サーバー側に負担は掛けないようにした方が良い？

これはもう仕様というかサーバの処理能力とか想定するクライアント数とかによって千差万別じゃないですかね。
一般論ではどういうこともできないと思います。
特定の状況をあげれば、そのときできるだけどういう方針をとるか、という話ならできるかもしれません。

お礼

回答ありがとうございます。
今日、ようやく実験でき、リクエストのタイミングの理解が間違っていることがわかりました。。
クラサバと違って即時にイベントをハンドル＆処理せず、サブミットのタイミングで一括で処理されるのですね。

ありがとうございました！