Является ли HTTPServerUtility.Transfer более удобным, чем Response.Redirect, в работе сайта в asp.net?

Question

Прямо сейчас я читаю о производительности и масштабируемости веб-сайта .net.

Я прочитал много постов в блогах и книгу о Microsoft по производительности и масштабируемости.

В последнем блоге , ссылка на который есть.

В этом блоге poing № 6, говорящий о "Использовать HTTPServerUtility.Transfer вместо Response.Redirect" ..

Является ли это более полезным для производительности веб-сайта и, как в блоге,

" Их следует использовать только при передаче людей на другой физический веб-сервер. Для любых передач на вашем сервере используйте .transfer! Вы сохраните много ненужных HTTP-запросов."

Кто-нибудь, помогите мне, как это более полезно в производительности, чем response.redirect?

Answer 1

Вы должны не , просто вслепую начать использовать Server.Transfer вместо Response.Redirect;они не являются просто вставными заменами.

Server.Transfer имеет еще одну страницу «выполнения», где текущая страница прекращает работу, давая свой вывод.Это сохраняет шаг Перенаправления - Перенаправление выдает клиенту ответ 302 - Moved с новым URL-адресом для загрузки, затем браузер делает этот новый запрос.Это то, что «спасается», когда вы используете Server.Transfer.

Но вы также можете потерять вещи;Например, ваш пользователь может запутаться, когда попытается сделать закладку на странице, загруженной с Server.Transfer, и обнаружит что-то совершенно неожиданное, потому что Server.Transfer не использовался с учетом этой возможности.

Вытакже необходимо проделать небольшую работу, чтобы убедиться, что значения вашего запроса правильно перенаправлены на «новую» страницу;Строка запроса, значения формы и значения серверных элементов управления.

Я бы назвал Server.Transfer что-то, что нужно учитывать, когда вы более продвинуты и хорошо разбираетесь в конвейере ASP.NET и протоколе HTTP, и в основном... у вас нет никаких вопросов, когда и почему вы хотели бы использовать его.

---

РЕДАКТИРОВАТЬ: Также;Я бы не стал воспринимать то, что вы читаете на этом веб-сайте, на который вы ссылаетесь слишком серьезно.Автор говорит, что вы должны избегать проверки на стороне сервера и делать это только на клиенте.Это, и многие из их собственных рекомендаций показывают крайне ограниченное знание ASP.NET/HTTP.Не позволяйте кому-то так заставлять вас тратить так много времени на что-то столь неважное.

Answer 2

Да Server.Transfer исключить Http Request; тем не менее, это не лучше всего подходит во всех сценариях. Вы должны знать, что каждый из них делает.

Response.Redierct

• Запрос браузера на страницу.
• Запрос процесса сервера Response.Redirect отправляет ответ с новым URL-адресом для загрузки с кодом ответа 302 Перемещено .
• Браузер получает 302 код состояния и запрашивает новый URL.
• Сервер получает новый URL и обрабатывает.

Server.Transfer

• Запрос браузера на страницу.
• Запрос процесса сервера затем сделать Server.Transfer отправляет ответ с новым URL для загрузки с кодом ответа 302 Перемещено .
• Браузер получает 302 код состояния и запрашивает новый URL.
• Запросить серверный процесс на новой странице и затем отправить ответ обратно.

Короче говоря, вы экономите одну поездку в оба конца с помощью Server.Transfer . Но браузер не смог получить новый URL.

Вывод: Если вы хотите проиндексировать свои URL-адреса поисковыми системами или хотите, чтобы ваши пользователи добавляли закладки в URL-адреса, то Server.Transfer вам не поможет.

Server.Transfer: поможет вам скрыть URL только от пользователя, браузера или поисковых систем.

Answer 3

Server.Transfer НЕ более полезен в производительности. Лучшая производительность зависит от того, что на самом деле выполняется на странице и от того, где вы вызываете передачу или перенаправление, но различия настолько малы, что вам нужнососредоточить внимание на том, что фактически делает transfer против redirect.

• Transfer добавляет много проблем, которые добавляют к вашей навигации от страницы к странице, например, пользователь видит то же имя страницы, ноСодержание отличается.
• Transfer также не может обрабатывать отправлять обратно функции asp.net.
• Когда вы используете transfer, вам всегда нужно знать, на каждой странице назад, на какой страницеВы показываете следующее, потому что вы всегда загружаете одну и ту же кодовую страницу.
• Если вы много используете Transfer, то сервер для каждой страницы должен загрузить и запустить 2 разных кода страницы для одного и того же результата.

Redirect с другойhand - это метод навигации и отображения результатов при обработке пользовательского ввода.Его чистый код на второй странице работает без проблем, обратной передачи и всего того, что работает одинаково.

Я предлагаю всем, кто редко использует Server.Transfer.

Вот пример, которыйПередача заставляет думать сложнее и медленнее.Если у вас есть работа, и затем вы показываете результат, и, скажем, эта работа занимает несколько секунд, если вы выполняете Transfer, для каждого поста назад или перезагружаете, работа должна быть запущена снова!.

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

Второй случай с перенаправлением, работа будет выполнена один раз и больше не вызываться, пользователь переместится на страницу результатов.

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

Я думаю, что не нужно слишком много разговоров, если вы будете практиковать их немного, вы сможете увидеть много мыслей и разных на реальных страницах.