5

Right now I am reading about .net website performance and scalability.

I read many blog posts and microsoft book about performance and scalability.

In last blog, linked here.

In this blog poing no.6 talking about
"Use HTTPServerUtility.Transfer instead of Response.Redirect"..

Is it more useful in performance of website and to the point as in the blog that,

"They should only be used when you are transferring people to another physical web server. For any transfers within your server, use .transfer! You will save a lot of needless HTTP requests."

Anyone help me how it is more useful in performance than response.redirect?

sikender
  • 5,883
  • 7
  • 42
  • 80
  • [Check This](http://stackoverflow.com/questions/521527/response-redirect-vs-server-transfer) and Also inline with your Question [This](http://stackoverflow.com/questions/855244/moving-from-page-a-to-page-b-in-asp-net-what-is-the-best-way) – V4Vendetta Apr 12 '11 at 07:18
  • @V$Vendetta: good article to read about it. But. Need more clarification regarding example. anyway Thanks. – sikender Apr 12 '11 at 07:24
  • The link you post in this question tells you *not to use server-side validation* !!!! I wouldn't listen to that person at all. – Andrew Barber Apr 12 '11 at 07:38

3 Answers3

6

You should not just blindly start using Server.Transfer instead of Response.Redirect; they are not simply drop-in replacements.

Server.Transfer has another page 'take up' execution where the current one leaves off, giving its output. This saves the Redirect step - A redirect issues a 302 - Moved response to the client, with the new URL to load, then the browser makes that new request. That is what is being 'saved' when you use Server.Transfer instead.

But you can also lose things; Like, your user can become confused when they try to bookmark a page that loaded with a Server.Transfer involved, and find something totally unexpected showing up because Server.Transfer was not used with that eventuality in mind.

You also have to do a little bit of work to make sure you get your request values marshalled over to the 'new' page properly; query string, form values, and the values of server-side controls.

I would call Server.Transfer something to consider when you are more advanced and knowledgeable of the ASP.NET pipeline and the HTTP protocol, and basically... you don't have any question at all when/why you would want to use it.

EDIT: Also; I would not take anything you read on that web site you link too seriously at all. The writer says that you should avoid server-side validation and instead only do it on the client. That, and many of their own recommendations show an extremely limited knowledge of ASP.NET/HTTP. Don't let someone like that make you spend so much time on something so unimportant.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
  • Need explanation with example to understand new topic like this. anyway Thanks. – sikender Apr 12 '11 at 07:24
  • My point exactly; you don't know enough to really know when/how to use the more advanced `Server.Transfer` yet... so don't use it. Don't spend hours and hours now learning what isn't going to be terribly useful to you overall. This is really something where you need to be fairly familiar with how ASP.NET works on an architectural level before you can make an intelligent decision. – Andrew Barber Apr 12 '11 at 07:28
  • I think you should have tell me about which thing is better to use for what reasons? I made 10+ asp.net websites and always I tried my best to improve it's performance. Now. I fully concentrate on performance and structure of asp.net website. SO, It's look perfect When my website will ready. so, I will say thanks if you help me on these topic. – sikender Apr 12 '11 at 07:30
  • Your answer is no: Do not go switching to `Server.Transfer` based on what you have read on that site. – Andrew Barber Apr 12 '11 at 08:11
1

Server.Transfer is NOT more useful in performance. The better performance is depent from what actuall run in the page and where you call the transfer or the redirect, but the diferent are so small that you need to focus what actuall transfer vs redirect do.

  • Transfer adds a lot of problems that add to your navigation from page to page, eg user see the same page name, but the content is diferent.
  • Transfer also can not handle post back asp.net functions.
  • When you use the transfer you always need to know on each post back what page you show next because you always load the same code page.
  • If you use a lot the Transfer, then server for every page need to load and run 2 different page code for the same result.

Redirect from the other hand is a method to navigate and show results to the processing of user input. Its clean, code on the second page work with out problems, postback and all that work the same.

I suggest to anyone to rare use the Server.Transfer.

Here is an example that Transfer make thinks complicate and slower. If you have a work to do, and then show result, and lets say that this work makes some seconds, if you make Transfer, on every post back, or reload the work must be run again !.

protected void Page_Load(object sender, EventArgs e)
{
    // function works
    Thread.Sleep(10000);
    Server.Transfer("Page2.aspx");
}

Second Case with redirect, the work will be done one time and not called again, user moves to the result page. 

protected void Page_Load(object sender, EventArgs e)
{
    // function works
    Thread.Sleep(10000);
    Response.Redirect("Page2.aspx");
}

I think, that there is no need for too many talks, if you practice them a little you can see many thinks and different in real pages.

Aristos
  • 66,005
  • 16
  • 114
  • 150
1

Yeah Server.Transfer eliminate Http Request; however, its not best suited in all scenarios. You should know what each do.

Response.Redierct

  • Browser request for a page.
  • Server process request then Response.Redirect sends response with new URL to load having Response code 302 Moved.
  • Browser receives 302 status code, and request new url.
  • Server receive new url and process.

Server.Transfer

  • Browser request for a page.
  • Server process request then do Server.Transfer sends response with new URL to load having Response code 302 Moved.
  • Browser receives 302 status code, and request new url.
  • Server process request on new page then send response back.

So in short you save one round trip with Server.Transfer. But the browser could not get new URL.

Conclusion: If you want to index your URLs by search engines or want your users to bookmark URLs then Server.Transfer will not help you.

Server.Transfer: will only help you to hide URL from user or browser or search engines.

Waqas Raja
  • 10,802
  • 4
  • 33
  • 38
  • 1
    Yup. In practice, cases where you might want to use `Server.Transfer` are probably indications of bad application architecture in the first place. – Andrew Barber Apr 12 '11 at 07:53
  • @Andrew, I use `Server.Transfer` when I have more than one Pages or handlers for same URL depending on query string variables, for instance `/xyz.aspx?var=1` then on xyz I do Server.Transfer to `page1.aspx` and for `/xyz.aspx?var=2` to `page2.aspx` e.t.c – Waqas Raja Apr 12 '11 at 08:04
  • 2
    I think URL rewriting would be a better way to handle that. But otherwise, my comment still stands. And anyway, as you noted; `Server.Transfer` isn't really the best thing to use all the time... unlike what that page says; It basically says you should *always* use `Server.Transfer` instead. Ugh! – Andrew Barber Apr 12 '11 at 08:07
  • URL Rewriting is the way to handle the variables, or you can use inside the page the logic that need to handle this variables. I totally agree with Andrew. – Aristos Apr 12 '11 at 09:19
  • @Aristos, its just a plain example which I told. – Waqas Raja Apr 12 '11 at 09:47
  • @Aristos, (@Andrew) I use Server.Transfer when I have more than one resultant Pages or handlers for same URL depending on processing result, for instance processing for PayPal on xyz I do Server.Transfer to paypalProcess.aspx and for Google to GoogleProcess.aspx e.t.c – Waqas Raja Apr 12 '11 at 09:51