Should i use HttpResponse.End() for a fast webapp?

views:

answers:

Should i use HttpResponse.End() for a fast webapp?

HttpResponse.End() seems to throw an exception according to msdn. Right now i have the choice of returning a value to say end thread (it only goes 2 functions deep) or i can call end().

I know that throwing exceptions is significantly slower (read the comment for a C#/.NET test) so if i want a fast webapp should i consider not calling it when it is trivially easy to not call it?

-edit- I do have a function call in certain functions and in the constructor in classes to ensure the user is logged in. So i call HttpResponse.End() in enough places although hopefully in regular site usage it doesn't occur too often.

+1 A:

You could use HttpResponse.Flush to push data to the client instead of terminating the request completely, avoiding the potential exception being thrown.

Note: That exception is not always thrown when Response.End is called, only when you prematurely end a request.

lark 2010-05-30 23:16:47

How do i know if it prematurely end or not? or how does the function know when it will end prematurely in the future? Does this mean i can call .end(); doSomeDBCode; doSomethingWithResponse() and have it end there?

acidzombie24 2010-05-30 23:19:27

If you call `Response.End` yourself, then it throws an exception. If you get to the end of the processing cycle then the system calls `Response.End` automatically: that one is not "premature".

Dean Harding 2010-05-31 00:19:56

+2 A:

Just use Response.End. Write your code for maintainability before you write it for performance.

Besides, the performance measure that matters for web apps is scalability. That is, you should not be asking "how fast can I process this single request", but "how many requests can I process at the same time?".

Exceptions do not affect your scalability, and in the grand scheme of things, an extra couple of microseconds on a single request is nothing: remember it'll be at least 50 milliseconds in network roundtrip: another 100 microseconds is noise.

Dean Harding 2010-05-30 23:34:52

Doesn't the amount of time it takes to process a single request, impact the amount requests you can handle during a given amount of time?How important is network latency as far as concurrent performance? One would think the app is helping other clients, while waiting for data to arrive from others due to latency. So I am not sure how a single clients latency impacts, overall concurrent performance.

Klinky 2010-05-31 00:24:20

@Klinky: in a way, yes, but improvements to scalability can be made independently (or even at the expense of) the response time of individual requests. My point was mostly that you should focus on scalability improvements and not worry *too much* about response times of individual requests (within reason, of course).

Dean Harding 2010-05-31 00:48:59

According to my ugly code i can get 13-20 exceptions per *200 milliseconds* (the test varied to much with 100ms). Or 48 per 500ms. So one exception can take 10ms which is more then noise. However i do like the write for maintainability and scalability part of the answer which is why its accepted. I am noting that it isnt *microseconds* but *milliseconds* ;) The poorly written but pretty suitable test is http://www.pastie.org/985017

acidzombie24 2010-05-31 00:58:16

@aciszombie24: Hmm, I've never tested the performance of exceptions before. Though I just ran your test and I get 10000 exceptions in 230 milliseconds (.NET Framework 4, 64-bit) so maybe they've made improvements?

Dean Harding 2010-05-31 01:05:58

additional note: Test was ran in debug mode in IDE. I tried in release mode in the visual studios IDE and got identical results. It looks like 1 exception takes roughly 10ms. The other part of the test is not relevant (returning 1 in a normal func call. It can be done >200k per 500ms. But we are testing exception time here. not function call.)

acidzombie24 2010-05-31 01:08:57

codeka: Interesting. Did you modify the source in any way (perhaps to clean up?). I am using visual studios 2010 targetting the default .net 4 client profile framework. -edit- hey its x86 by default. strange. However its very interesting taht we have VASTLY different results. -edit- i am getting (guessing) 60% of the speed when using x64 build. I thought it would have been faster.

acidzombie24 2010-05-31 01:10:06

@acidzombie: no, but running it from the IDE (with F5) is really slow. Did you try Ctrl+F5, or running it from the command-line?

Dean Harding 2010-05-31 01:12:28

There we go. 19193 on the command line using 64bit and a slower result using 32bit. Ok so i take this back. On my machine 1ms = 38exceptions so your right. I guess it is noise. But now i am happy to have actual (but maybe not scientific) benchmarks.

acidzombie24 2010-05-31 01:18:06

Throwing Exception can be pretty slow when you attached a profiler (as you already saw). It is possible to have some sort of custom exception profiler attached in your production environment to register all thrown exceptions, and in that case throwing exceptions can be really bad for performance. However, I've never seen any organization do this, so it is pretty rare. I agree with Codeka that a ThreadAbort exceptions would normally not have any noticeable performance difference in a web app.

Steven 2010-05-31 06:59:08

ansaurus

tags:

views:

answers:

Should i use HttpResponse.End() for a fast webapp?

related questions