¿Puede “EndResponse” boost el rendimiento de la página ASP.Net?

Tengo un Response.Redirect en mi página de empleado. Redirige a la página Salario.

 Response.Redirect ("Salary.aspx"); 

Funcionaba bien hasta que agregué el manejo de excepciones como a continuación.

 try { Response.Redirect ("Salary.aspx"); } catch(Exception ex) { //MyLog(); throw new Exception(); } //Remaining code in event handler 

Esto provocó una nueva excepción que decía “Se estaba endResponse hilo”. Llegué a saber que esto se puede evitar estableciendo endResponse como falso para el redireccionamiento.

 Response.Redirect(url, false); Context.ApplicationInstance.CompleteRequest(); 

Explicación de la nueva excepción: siempre arroja la excepción pero la maneja el marco. Desde que agregué un try..catch fue capturado allí (y estoy lanzando una nueva excepción)

Nota: CompleteRequest omite más filtros y módulos HTTP, pero no omite otros eventos en el ciclo de vida de la página actual.

Nota: Response.Redirect lanza esta excepción al procesamiento final de la página actual. ASP .Net maneja esta excepción y llama a ResetAbort para continuar con el procesamiento.

PREGUNTA

  1. Si “establecer endResponse como falso” puede boost el rendimiento ya que no se lanza la excepción?
  2. Si “establecer endResponse como falso” puede disminuir el rendimiento ya que los eventos del ciclo de vida de la página no se terminan?

TRAMPA

  1. Si establece endResponse como false , se ejecutará el código restante en eventhandler. Entonces, debemos hacer una verificación if para el código restante (Verificar: si no se cumplieron los criterios de redirección).

Referencia

  1. ¿Por qué Response.Redirect causa System.Threading.ThreadAbortException?
  2. La excepción de ASP.NET “Se estaba anulando el hilo” hace que el método salga

Finalizar la respuesta ( Response.Redirect(url) o Response.Redirect(url, true) ) no tendrá un mejor rendimiento que Response.Redirect(url, false) . Con false , ya que tiene control sobre la ejecución del código, simplemente no puede ejecutar más código en el caso cuando va a redirigir al usuario.

Esto se especifica en la entrada de MSDN para Response.Redirect() :

Si especifica true para el parámetro endResponse, este método llama al método End para la solicitud original, que arroja una excepción ThreadAbortException cuando finaliza. Esta excepción tiene un efecto perjudicial en el rendimiento de la aplicación web , por lo que se recomienda pasar falso para el parámetro endResponse.

Sí, debes preocuparte por los eventos del ciclo de vida de la página, como anotaste. No debe continuar ejecutando los eventos de página si va a redirigir al usuario ( no solo para el rendimiento ). Hace poco escribí un breve ejemplo que muestra lo que puede suceder con una pobre encoding / planificación si no lo hace.

La conclusión de esa publicación es que Response.Redirect() devuelve un 302 al navegador. Existe un potencial de problemas cuando usa Response.Redirect(url, false) ya que la ejecución de la página continúa, y el usuario puede elegir ignorar el 302 y en su lugar ver la página que se habría renderizado … por lo que necesita tome medidas para asegurarse de que no vean nada que no quiera que vean. El complemento NoRedirect para Firefox es útil al probar esto.

Para obtener el mejor rendimiento: use "false" como parámetro endResponse , asegúrese de que no está ejecutando ningún código adicional y asegúrese de que la página no muestre ninguna información que no desee que el usuario vea si ignora el 302.