在 asp.net 中的网站性能方面,HTTPServerUtility.Transfer 是否比 Response.Redirect 更有用?
现在我正在阅读有关 .net 网站性能和可扩展性的内容。
我读了很多关于性能和可扩展性的博客文章和微软书籍。
在上一篇博客中,链接到此处。
在这篇博客的第 6 篇文章中,谈论
“使用 HTTPServerUtility.Transfer 而不是 Response.Redirect”..
它对网站性能更有用吗?
“仅当您将人员转移到另一个物理 Web 服务器时才应使用它们。对于服务器内的任何转移,请使用 .transfer!您将节省大量不必要的 HTTP 请求。”
任何人都可以帮助我如何它在性能上比response.redirect更有用吗?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您不应该盲目地开始使用
Server.Transfer
而不是Response.Redirect
;它们不仅仅是简单的替代品。Server.Transfer 在当前页面停止的地方“占用”执行另一个页面,并给出其输出。这节省了重定向步骤 - 重定向向客户端发出
302 - Moved
响应,并加载新的 URL,然后浏览器发出新请求。这就是当您使用 Server.Transfer 时所“保存”的内容。但你也可能会失去一些东西;例如,当您的用户尝试为加载了涉及
Server.Transfer
的页面添加书签时,他们可能会感到困惑,并发现完全意外的内容出现,因为Server.Transfer
没有考虑到这种可能性而使用。您还必须做一些工作以确保将请求值正确编组到“新”页面;查询字符串、表单值和服务器端控件的值。
当您对 ASP.NET 管道和 HTTP 协议更加高级和了解时,我会考虑将
Server.Transfer
称为需要考虑的东西,并且基本上...当/时您根本没有任何问题为什么你想使用它。编辑:另外;我不会太认真地对待您在链接的网站上读到的任何内容。作者说,您应该避免服务器端验证,而只在客户端进行验证。他们自己的许多建议都表明他们对 ASP.NET/HTTP 的了解极其有限。不要让这样的人让你花那么多时间在如此不重要的事情上。
You should not just blindly start using
Server.Transfer
instead ofResponse.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 a302 - 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 useServer.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 becauseServer.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.
是的,
Server.Transfer
消除了Http请求;然而,它并不是最适合所有场景。你应该知道每个人的作用。Response.Redierct
Response.Redirect
发送带有新 URL 的响应以加载具有响应代码 302 Moved 的响应。Server.Transfer
Server.Transfer
发送带有新URL的响应以加载响应代码302 Moved。浏览器接收 302 状态码,并请求新的 url。简而言之,您可以使用 Server.Transfer 节省一次往返时间。但浏览器无法获取新的 URL。
结论:如果您希望搜索引擎为您的 URL 编制索引或希望您的用户为 URL 添加书签,那么
Server.Transfer
将无济于事。Server.Transfer:只会帮助您对用户、浏览器或搜索引擎隐藏 URL。
Yeah
Server.Transfer
eliminate Http Request; however, its not best suited in all scenarios. You should know what each do.Response.Redierct
Response.Redirect
sends response with new URL to load having Response code 302 Moved.Server.Transfer
Server.Transfer
sends response with new URL to load having Response code 302 Moved.Browser receives 302 status code, and request new url.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.
Server.Transfer 在性能方面并不更有用。更好的性能取决于页面中实际运行的内容以及调用传输或重定向的位置,但差异很小,因此您需要关注
transfer
与redirect
的实际作用是什么。Transfer
增加了很多问题添加到从页面到的导航
页面,例如用户看到相同的页面名称,但内容不同。
转账
也无法处理回发 asp.net 函数。
transfer
时,您始终需要知道每次回发时接下来显示的页面,因为您总是加载相同的代码页。Transfer
,那么每个页面的服务器都需要加载并运行 2 个不同的页面代码以获得相同的结果。另一方面,重定向是一种导航和显示处理用户输入结果的方法。它干净,第二页上的代码工作没有问题,回发和所有工作都是一样的。
我建议任何人都不要使用
Server.Transfer
。下面是一个例子,Transfer 使思考变得复杂且缓慢。如果您有一项工作要做,然后显示结果,并且可以说这项工作需要几秒钟,如果您进行传输,则每次回发或重新加载工作都必须再次运行!
第二种情况是重定向,工作将完成一次,不会再次调用,用户移动到结果页面。
我认为,没有必要讲太多,只要稍微练习一下,就可以在实际页面中看到很多想法和不同之处。
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
vsredirect
do.Transfer
adds a lot of problems thatadd to your navigation from page to
page, eg user see the same page name, but the content is diferent.
Transfer
also can not handlepost back asp.net functions.
transfer
you always need to know on each post back what page you show next because you always load the same code page.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 !.
Second Case with redirect, the work will be done one time and not called again, user moves to the result page.
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.