.NET CLR Exceptions\# of Exceps Thrown / sec thrown during execution of Server.Transfer method
Hello there,
When trying to use the server.transfer method to redirect to a different url, the thread.abort exception gets thrown. To avoid this we tried using the overloaded method Server.Transfer(string,bool) as suggested by MS and many others.
We tried both the boolean parameters for our study.
But this seems to not work. The number of execptions thrown are significantly higher. Can anyone give us pointers as to how to handle this?
Currently we are using the server.transfer method to navigate between the pages. Is there any other method other than this or Response.Redirect/Server.Execute (These too throw the similar exception) to navigate.
Appreciate your help greatly.
Thanks and Regards
Madhu
Eh? Can you elaborate one what your doing and what your trying to accomplish? I think you might architectually be making some bad designs. What exceptions are you talking about specifically.
Server.Transfer should not really be used only in certain conditions. The only thing that I can think of is like maybe a security violations or something as the only real valid reason to have Server.Transfer
Server.Transfer immediately stops execution of the page and transfers to another page, so yes you will get a lot of funny things going on there if your not expecting your page execution to just halt. While I have never investigated it I would imagine that you get the thread abord exception because each asp page fires in as a new thread, which then taps into the asp.net worker process thread to actually execute the page. This should never be used as general navigation.
Server.Execute also could cause you problems it is actually executing a different page than the one requested by the browser, so your page requested should really be doing much if any processing.
Response.Redirect can be used but again it is going to stop executing everything below it and redirect. However this works by sending Page Moved to the browser and sends the new URL with it so the browser then rerequests the new page from the server. Typically I would use response.Redirect after submitting a form to redirect back to a thank you page or something this way if a user hits refresh it doesn't resubmit.
So now I am trying to figure out why you would be using any of these to navigate with. If you are trying to track page requests and where people are moving around from and how they are browsing your site. I would recomend just using regular URLs so when someone clicks on a link it goes to that page. Then in your global.cs or global.vb depending on language on the Application Begin request check to see which page was the referer and then record that, let your pages execute like normal.
If that doesn't help you can you explain more of what you are trying to do.
Thanks Jeff for your response. This is an enterprise application and has been built using Server.Transfer and Response.Redirect methods to navigate the pages. As of now there is no problem with the way the application behaves.
When trying out the stress/performance testing using ACT, I found that the parameter .NET CLR Exceptions\# of Exceps Thrown / sec which should be ideally 5% of the RPS is somewhere like 60 - 80%. This was worrying. The net effect would be the % time the processor would spend in clearing the resultant garbage would be high and reduce the system performance.
The attempt made here is to understand the significance of this parameter as a performance measure. Whether trying to reduce the exception inherent to the CLR would enhance the performance. If so what are the means of doing the same.
Please advise.
The second parameter of the server.transfer (preserveForm) indicates whether you want to carry over your (querystring) and forms data over to the next page. If you wrap a error handler around this you will get a threadabortexception by default. This is by design and is because the HttpRequest is ended when you do a transfer and can't take further processing. See this MSDN article and this article for more details.
Have you tracked your exceptions back to your server.transfer or is this an assumption? Throwing too many exceptions can impact performance in the long run and yes a small part of it is the actual allocation of those exceptions on the heap (that require GC later) but it really goes beyond that. If you're curious why check out this blog post http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx.
There is obviously something going on and that many exceptions is generally not a good thing. Are you using exceptions in any normal flow of control or are you using exceptions for truly exception situations that you try to handle?
If you are not sure what the source is are you doing any logging? There are several different methods you can use to find out what is throwing all the exceptions but before going down that road some more details would be helpful.
Regards,
Josh Carlisle
EDIT:
- sorry for some of the rehash of Jeff's comments - I was responding and I got sidetracked before finishing it and posted after Jeff's initial comments. Jeff's comments are on target
this is by design.
For more information have a look at this:
http://support.microsoft.com/default.aspx?scid=kb;en-us;817266
Every time Server.Transfer is called it throws an exception. So you probably use Server.Transfer 50-80% of the time.
 Madhu Venugopal wrote: |
| Thanks Jeff for your response. This is an enterprise application and has been built using Server.Transfer and Response.Redirect methods to navigate the pages. As of now there is no problem with the way the application behaves. When trying out the stress/performance testing using ACT, I found that the parameter .NET CLR Exceptions\# of Exceps Thrown / sec which should be ideally 5% of the RPS is somewhere like 60 - 80%. This was worrying. The net effect would be the % time the processor would spend in clearing the resultant garbage would be high and reduce the system performance. The attempt made here is to understand the significance of this parameter as a performance measure. Whether trying to reduce the exception inherent to the CLR would enhance the performance. If so what are the means of doing the same. Please advise.
|
|
Madhu,
As stated by others, what you are seeing is by design. Unfortunately, while ASP and ASP.NET are syntactically the same (if using VB of course), the implementation is different (as you have seen with the exceptions being thrown).
If you are transferring to another page because you need to redirect to that page, then there is little that you can do about this. What you might want to consider (if possible), is an IHttpHandler implementation that would be able to perform some of the logic of where to navigate to before you start processing the page. This would help reduce the number of exceptions thrown, and possibly increase performance.
However, if you are not seeing that it is impacting performance, then I would recommend that you don't change it. Yes, applications can always be faster, but at the same time, if the need is not there, you have to ask if a major redesign (which does not use Transfer) is needed.
Also, if you are calling Transfer to move to a page because that page has business logic that the current one does not, then I would say that must be changed.
Hope this helps.
- Nicholas Paldino
- mvp@spam.guard.caspershouse.com
