Diez formas principales de mejorar el rendimiento de las aplicaciones ASP.Net
Autor：Eve Cole
Fecha de actualización：2009-06-30 15:49:49
Este artículo analiza:
Mitos comúnmente contados sobre cómo mejorar el rendimiento de las aplicaciones asp.net Consejos útiles para mejorar el rendimiento de las aplicaciones asp.net
Recomendaciones para operar bases de datos con aplicaciones Asp.net
Almacenamiento en caché y procesamiento en segundo plano en Asp.net
Hoy en día, escribir una aplicación web ASP.NET se ha vuelto muy simple y muchos programadores no están dispuestos a perder tiempo creando una aplicación con buen rendimiento. Este artículo analizará las diez formas principales de mejorar el rendimiento de las aplicaciones web. No limitaré mi discusión solo a las aplicaciones ASP.NET, ya que son solo un subconjunto de aplicaciones web. Este artículo tampoco puede proporcionar una guía completa para mejorar el rendimiento de las aplicaciones web, ya que eso requeriría la extensión de un libro. Este artículo sólo proporciona un buen punto de partida para mejorar el rendimiento de las aplicaciones web. (Lo único que nos queda es estudiar poco a poco por nuestra cuenta).
Fuera del trabajo, suelo escalar en roca. Antes de cada escalada, reviso el mapa de la ruta de escalada y leo los consejos de escaladores exitosos anteriores. Porque necesitamos su experiencia exitosa. De manera similar, cuando necesita modificar un programa con problemas de rendimiento o desarrollar un sitio web de alto rendimiento, también necesita aprender a escribir una aplicación web de alto rendimiento.
Mi experiencia personal proviene principalmente de trabajar como administrador de programas en el grupo asp.net de Microsoft, ejecutar y administrar el sitio web www.asp.net y ayudar en el desarrollo de Community Server (que es una versión integrada y mejorada de asp.net Forums). , .Text y software nGallery). Creo que estas experiencias pueden ayudarme.
Podría pensar en dividir su aplicación en diferentes capas lógicas. Es posible que también haya oído hablar de la arquitectura física de tres niveles o arquitectura de N niveles, que es el modelo de arquitectura más utilizado. Asigna físicamente diferentes funciones de programa a varios hardware para su ejecución. De esta forma, si queremos mejorar el rendimiento de la aplicación, añadiendo algo de hardware podemos conseguir el objetivo. Es lógico que este método pueda mejorar el rendimiento de la aplicación, pero debemos evitar su uso. Por lo tanto, siempre que sea posible, debemos colocar la página ASP.NET y los componentes que utiliza en una aplicación.
Debido a la implementación distribuida y al uso de servicios web o de comunicación remota, el rendimiento de la aplicación se reducirá en un 20 % o más.
La capa de datos es un poco diferente. Es mejor implementarla de forma independiente y utilizar un hardware independiente para ejecutarla. A pesar de esto, la base de datos sigue siendo el cuello de botella del rendimiento de las aplicaciones. Por lo tanto, cuando desee optimizar su programa, lo primero que le viene a la mente debería ser optimizar la capa de datos.
Antes de modificar un área de su aplicación que está causando problemas de rendimiento, querrá asegurarse de que el programa que está causando el problema se vea bien. Los perfiladores de rendimiento son muy útiles para encontrar en qué parte de su aplicación está tardando. Estos son lugares que no podemos sentir intuitivamente.
Este artículo analiza dos tipos de optimizaciones de rendimiento: una es una gran optimización de rendimiento (grandes optimizaciones), como el uso de la caché de asp.net, la otra es una pequeña optimización de rendimiento (pequeña optimización). A veces, pequeñas optimizaciones de rendimiento pueden resultar muy útiles. Realiza un pequeño cambio en su código y lo llama mil o diez mil veces a la vez. Realice una gran optimización del rendimiento y verá una gran mejora en la velocidad de su aplicación. Una pequeña optimización del rendimiento puede mejorar solo un microsegundo por solicitud, pero si la cantidad de solicitudes por día es grande, la aplicación tendrá una mejora significativa en el rendimiento.
Rendimiento de la capa de datos
Cuando desee optimizar el rendimiento de una aplicación, puede trabajar en el siguiente orden: ¿Su código necesita acceder a la base de datos? Si es así, ¿con qué frecuencia se debe acceder a la base de datos? Asimismo, este método de prueba también se puede utilizar en código de programa que utiliza servicios web o comunicación remota. Este artículo no abordará la cuestión de la optimización de programas mediante servicios web y comunicación remota.
Si hay una solicitud en su código que debe acceder a la base de datos y ve un código que implementa la misma función en otro lugar, primero debe optimizarlo. Modifique, mejore y continúe con las pruebas, a menos que tenga un problema de rendimiento muy grande, es mejor invertir su tiempo en optimizar las consultas, conectarse a la base de datos, devolver el tamaño del conjunto de datos y el tiempo que lleva devolver una consulta.
Con base en el resumen de la experiencia, echemos un vistazo a diez experiencias que pueden ayudarlo a mejorar el rendimiento de su aplicación. Las explicaré en orden de mayor a menor en términos de cuánto mejoran la eficiencia.
1. Devolver múltiples conjuntos de datos
Verifique el código de acceso a su base de datos para ver si hay solicitudes que regresan varias veces. Cada viaje de ida y vuelta reduce la cantidad de solicitudes por segundo a las que su aplicación puede responder. Al devolver múltiples conjuntos de resultados en una sola solicitud de base de datos, reduce el tiempo necesario para comunicarse con la base de datos, hace que su sistema sea escalable y reduce la carga de trabajo en el servidor de la base de datos para responder a las solicitudes.
Si está utilizando sentencias de SQL dinámico para devolver varios conjuntos de datos, le recomiendo que utilice procedimientos almacenados en lugar de sentencias de SQL dinámico. La cuestión de escribir lógica empresarial en procedimientos almacenados es un poco controvertida. Pero creo que escribir lógica empresarial en procedimientos almacenados puede limitar el tamaño del conjunto de resultados devuelto, reducir el tráfico de datos de la red y eliminar la necesidad de filtrar datos en la capa lógica.
Utilice el método ExecuteReader del objeto SqlCommand para devolver un objeto comercial fuertemente tipado y luego llame al método NextResult para mover el puntero del conjunto de datos para ubicar el conjunto de datos. El ejemplo 1 muestra un ejemplo de devolución de múltiples objetos ArrayList fuertemente tipados. Devolver solo los datos que necesita de la base de datos puede reducir en gran medida el consumo de memoria de su servidor.
2. Paginar los datos
ÁSPID. NET's DataGrid tiene una característica muy útil: la paginación. Si DataGrid permite la paginación, solo descargará los datos de una determinada página en un momento determinado. Además, tiene una barra de navegación para la paginación de datos, que le permite elegir navegar por una determinada página y descargar solo una página. datos a la vez.
Pero tiene una pequeña desventaja, es decir, debes vincular todos los datos al DataGrid. En otras palabras, su capa de datos debe devolver todos los datos y luego DataGrid filtra los datos requeridos por la página actual y los muestra. Si hay un conjunto de resultados de 10,000 registros que deben paginarse usando DataGrid, suponiendo que DataGrid solo muestra 25 datos por página, significa que se descartarán 9975 datos en cada solicitud. Cada solicitud debe devolver un conjunto de datos tan grande, lo que tiene un gran impacto en el rendimiento de la aplicación.
Una buena solución es escribir un procedimiento almacenado de paginación. El ejemplo 2 es un procedimiento almacenado de paginación para la tabla de pedidos de la base de datos Northwind. Solo necesita pasar el número de página actual y la cantidad de elementos que se muestran en cada página, y el procedimiento almacenado devolverá los resultados correspondientes.
En el lado del servidor, escribí especialmente un control de paginación para manejar la paginación de datos. Aquí, utilicé el primer método y devolví dos conjuntos de resultados en un procedimiento almacenado: el número total de registros de datos y el conjunto de resultados requerido.
El número total de registros devueltos depende de la consulta que se esté ejecutando, por ejemplo, una condición donde puede limitar el tamaño del conjunto de resultados devuelto. Debido a que el número total de páginas debe calcularse en función del tamaño de los registros del conjunto de datos en la interfaz de paginación, se debe devolver el número de registros en el conjunto de resultados. Por ejemplo, si hay 1.000.000 de registros en total, si utiliza la condición donde, puede filtrar para devolver solo 1.000 registros. La lógica de paginación del procedimiento almacenado debe saber cómo devolver los datos que deben mostrarse.
3. Grupo de conexiones
Usar TCP para conectar su aplicación a la base de datos es costoso (y requiere mucho tiempo). Los desarrolladores de Microsoft pueden usar grupos de conexiones para reutilizar las conexiones de la base de datos. En lugar de utilizar TCP para conectarse a la base de datos para cada solicitud, el grupo de conexiones solo crea una nueva conexión TCP cuando no hay una conexión válida. Cuando se cierra una conexión, se colocará en el grupo y aún mantendrá una conexión con la base de datos, lo que reducirá la cantidad de conexiones TCP a la base de datos.
Eso sí, debes prestar atención a aquellas conexiones que olvidaste cerrar. Debes cerrarlo inmediatamente después de cada uso. Lo que quiero enfatizar es: no importa lo que digan, el GC (recolector de basura) en el marco .net siempre llamará al método Cerrar o Disponer del objeto de conexión para cerrar explícitamente su conexión una vez que haya terminado de usar el objeto de conexión. No espere que CLR cierre la conexión en el tiempo que imagina. Aunque CLR eventualmente destruirá el objeto y cerrará la conexión, no estamos seguros de cuándo hará estas cosas.
Para utilizar la optimización del grupo de conexiones, existen dos reglas: primero, abra la conexión, procese los datos y luego cierre la conexión. Si tiene que abrir o cerrar la conexión varias veces por solicitud, es mejor que abrir una conexión lateral todo el tiempo y pasarla a cada método. En segundo lugar, utilice la misma cadena de conexión (o el mismo ID de usuario, cuando utilice la autenticación integrada). Si no utiliza la misma cadena de conexión, por ejemplo, si utiliza una cadena de conexión basada en el usuario que inició sesión, esto no aprovechará las funciones de optimización del grupo de conexiones. Si utiliza argumentos integrados, no podrá aprovechar al máximo la función de optimización del grupo de conexiones porque hay muchos usuarios. .NET CLR proporciona un contador de rendimiento de datos, que es muy útil cuando necesitamos realizar un seguimiento de las características de rendimiento del programa, incluido el seguimiento del grupo de conexiones.
Siempre que su aplicación se conecta a un recurso en otra máquina, como una base de datos, debe concentrarse en optimizar el tiempo que le lleva conectarse al recurso, el tiempo que le lleva recibir y enviar datos y la cantidad de veces que regresa. . Optimizar cada salto de proceso en su aplicación es el punto de partida para mejorar el rendimiento de su aplicación.
La capa de aplicación contiene la lógica para conectarse a la capa de datos, transferir datos a instancias de las clases correspondientes y el procesamiento empresarial. Por ejemplo, en Community Server, debe ensamblar una colección de foros o subprocesos y luego aplicar la lógica empresarial, como la autorización. Más importante aún, debe completar la lógica de almacenamiento en caché aquí.
4. APE. API de caché NET
Antes de escribir una aplicación, lo primero que debe hacer es hacer que la aplicación maximice el uso de las capacidades de almacenamiento en caché de ASP.NET.
Si su componente se va a ejecutar en una aplicación Asp.net, solo necesita hacer referencia a System.Web.dll en su proyecto. Luego use la propiedad HttpRuntime.Cache para acceder al caché (también se puede acceder a través de Page.Cache o HttpContext.Cache).
Existen varias reglas para almacenar datos en caché. En primer lugar, los datos se pueden utilizar con frecuencia y se pueden almacenar en caché. En segundo lugar, la frecuencia de acceso a los datos es muy alta, o la frecuencia de acceso de un determinado dato no es alta, pero su ciclo de vida es muy largo. Es mejor almacenar en caché dichos datos. El tercero es un problema que a menudo se ignora: a veces almacenamos en caché demasiados datos. Generalmente en una máquina X86, si los datos que desea almacenar en caché superan los 800 M, se producirá un error de desbordamiento de memoria. Entonces el caché es limitado. En otras palabras, debe estimar el tamaño del conjunto de caché y limitar el tamaño del conjunto de caché a menos de 10; de lo contrario, puede causar problemas. En Asp.net, si el caché es demasiado grande, se informará un error de desbordamiento de memoria, especialmente si se almacena en caché un objeto DataSet grande.
A continuación se muestran algunos mecanismos de almacenamiento en caché importantes que debe comprender. Primero, el caché implementa el principio de "usado más recientemente" (un algoritmo utilizado menos recientemente). Cuando hay pocos cachés, borrará automáticamente los cachés inútiles. En segundo lugar, el principio de eliminación forzada de "dependencias condicionales" (dependencias de vencimiento), las condiciones pueden ser tiempo, palabras clave y archivos. El tiempo como condición es el más utilizado. Se agrega una condición más estricta en asp.net2.0, que es la condición de la base de datos. Cuando los datos en la base de datos cambian, se fuerza el borrado del caché. Para obtener una visión más profunda de las dependencias condicionales de las bases de datos, consulte la columna Cutting Edge de Dino Esposito en la edición de julio de 2004 de MSDN Magazine. La arquitectura de caché de Asp.net se muestra en la siguiente figura:
5. Almacenamiento en caché previo a la solicitud
Anteriormente mencioné que incluso si solo realizamos una pequeña mejora en el rendimiento en algunos lugares, podemos obtener una gran mejora en el rendimiento. Realmente me gusta usar el almacenamiento en caché de solicitud previa para mejorar el rendimiento del programa.
Aunque la API de caché está diseñada para guardar datos durante un período de tiempo determinado, el caché de solicitud previa solo guarda el contenido de una solicitud determinada durante un período de tiempo determinado. Si la frecuencia de acceso de una determinada solicitud es alta, y esta solicitud solo necesita extraer, aplicar, modificar o actualizar los datos una vez. Luego, la solicitud se puede almacenar en caché previamente. Pongamos un ejemplo para ilustrar.
En la aplicación del foro CS, el control del servidor de cada página requiere datos personalizados para determinar su apariencia, determinar qué hoja de estilo usar y otras cosas personalizadas. Es posible que algunos de los datos aquí deban guardarse durante mucho tiempo, pero otras veces no. Por ejemplo, los datos de la piel de un control solo deben aplicarse una vez y pueden usarse todo el tiempo.
Para implementar el almacenamiento en caché previo a la solicitud, use la clase HttpContext de Asp.net. Se crea una instancia de la clase HttpContext en cada solicitud y se puede acceder a ella a través de la propiedad HttpContext.Current en cualquier lugar durante la solicitud. La clase HttpContext tiene una propiedad de colección de elementos y todos los objetos y datos se agregan a esta colección y se almacenan en caché durante la solicitud. Al igual que usa Cache para almacenar en caché los datos a los que se accede con frecuencia, puede usar HttpContext.Items para almacenar en caché los datos básicos que se utilizan en cada solicitud. La lógica detrás de esto es simple: agregamos datos a HttpContext.Items y luego leemos los datos.
6. Procesamiento en segundo plano
Con el método anterior tu aplicación debería ejecutarse muy rápido, ¿verdad? Pero en algún momento, es posible que se realice una tarea que requiere mucho tiempo en una solicitud del programa. Como enviar correos electrónicos o comprobar la exactitud de los datos enviados, etc.
Cuando integramos asp.net Forums 1.0 en CS, descubrimos que enviar una nueva publicación sería muy lento. Cada vez que se agrega una nueva publicación, la aplicación primero debe verificar si la publicación es un duplicado, luego filtrarla usando el filtro de "palabra incorrecta", verificar el código de la imagen adjunta, indexar la publicación, agregarla a la cola apropiada y validar. su archivo adjunto y, finalmente, enviar el correo electrónico al buzón de su suscriptor. Obviamente, esto es mucho trabajo.
El resultado es que dedica mucho tiempo a indexar y enviar correos electrónicos. Indexar publicaciones es una operación que requiere mucho tiempo y enviar correos electrónicos a los suscriptores requiere conectarse al servicio SMTP y luego enviar un correo electrónico a cada suscriptor. A medida que aumenta el número de suscriptores, el tiempo que lleva enviar correos electrónicos aumentará.
No es necesario activar la indexación y el envío de correos electrónicos en cada solicitud. Lo ideal sería procesar estas operaciones en lotes, enviando solo 25 correos electrónicos a la vez o que todos los correos electrónicos nuevos se envíen cada 5 minutos. Decidimos usar el mismo código que el prototipo de caché de la base de datos, pero falló, por lo que tuvimos que volver a VS.NET 2005.
Encontramos la clase Timer en el espacio de nombres System.Threading. Esta clase es muy útil, pero pocas personas la conocen y aún menos desarrolladores web la conocen. Una vez que crea una instancia de esta clase, la clase Timer llamará a la función de devolución de llamada especificada desde un subproceso en el grupo de subprocesos cada vez especificada. Esto significa que su aplicación ASP.NET puede ejecutarse incluso cuando no hay solicitudes. Ésta es la solución que se abordará más adelante. Puede ejecutar el trabajo de indexación y envío de correo electrónico en segundo plano en lugar de tener que ejecutarlo en cada solicitud.
Hay dos problemas con la tecnología de ejecución en segundo plano. El primero es que cuando se desinstala el dominio de su aplicación, la instancia de la clase Timer dejará de ejecutarse. Es decir, no se llamará al método de devolución de llamada. Además, debido a que hay muchos subprocesos ejecutándose en cada proceso de CLR, le resultará difícil conseguir un subproceso para que Timer lo ejecute, o podrá ejecutarlo, pero se retrasará. La capa Asp.net debe usar esta técnica lo menos posible para reducir la cantidad de subprocesos en el proceso, o solo permitir que las solicitudes utilicen una pequeña parte de los subprocesos. Por supuesto, sólo puedes usarlo si tienes mucho trabajo asincrónico.
No hay suficiente espacio para publicar el código aquí. Puede descargar el programa de muestra desde http://www.rob-howard.net/ . Descargue el programa de muestra Blackbelt TechEd 2004.
7. Almacenamiento en caché de resultados de página y servicios de proxy
Asp.net es su capa de interfaz (o debería serlo), contiene páginas, controles de usuario, controles de servidor (HttpHandlers y HttpModules) y el contenido que generan. Si tiene una página Asp.net que genera datos html, xml, imgae u otros, y usa código para generar el mismo contenido de salida para cada solicitud, es necesario que considere usar el almacenamiento en caché de resultados de la página.
Puede hacer esto simplemente copiando la siguiente línea de código en su página:
<%@ PageOutputCache VaryByParams=”ninguno” Duración=”60” %>
Puede utilizar eficazmente la página generada en la primera solicitud para generar el contenido almacenado en caché y regenerar el contenido de la página después de 60 segundos. En realidad, esta tecnología se implementa utilizando alguna API de caché de bajo nivel. Hay varios parámetros que se pueden configurar para el almacenamiento en caché de la salida de la página, como el parámetro VaryByParams mencionado anteriormente. Este parámetro indica cuándo activar las condiciones de reimpresión. También puede especificar la salida en caché en el modo de solicitud Http Get o Http Post. Por ejemplo, cuando configuramos este parámetro en VaryByParams="Report", la salida solicitada por default.aspx?Report=1 o default.aspx?Report=2 se almacenará en caché. El valor de un parámetro puede ser varios parámetros separados por punto y coma.
Mucha gente no se da cuenta de que cuando se utiliza el almacenamiento en caché de resultados de página, ASP.NET también generará un conjunto de encabezados HTTP (encabezado HTTP) y lo guardará en el servidor de caché descendente. Esta información se puede utilizar para la seguridad de Internet de Microsoft y para acelerar el proceso. velocidad de respuesta del servidor. Cuando se restablece el encabezado de la caché HTTP, el contenido solicitado se almacenará en caché en el recurso de red. Cuando el cliente solicite el contenido nuevamente, ya no obtendrá el contenido del servidor de origen, sino que lo obtendrá directamente del caché.
Aunque el uso del almacenamiento en caché de resultados de páginas no mejora el rendimiento de su aplicación, sí reduce la cantidad de veces que el contenido de la página en caché se carga desde el servidor. Por supuesto, esto se limita a almacenar en caché páginas accesibles para usuarios anónimos. Porque una vez que la página se almacena en caché, ya no se pueden realizar operaciones de autorización.
8. Utilice el almacenamiento en caché del kernel de IIS6.0
Si su aplicación no se ejecuta en IIS 6.0 (Windows Server 2003), entonces ha perdido algunas formas excelentes de mejorar el rendimiento de la aplicación. En el séptimo método, hablé sobre cómo utilizar el almacenamiento en caché de resultados de páginas para mejorar el rendimiento de la aplicación. En IIS5.0, cuando llega una solicitud a IIS, IIS la transferirá a asp.net. Cuando se aplica el caché de salida de la página, HttpHandler en ASP.NET recibirá la solicitud y HttpHandler transferirá el contenido del caché. Sácalo y devuélvelo.
Si está utilizando IIS6.0, tiene una característica muy buena llamada Kernel Caching y no necesita modificar ningún código en el programa asp.net. Cuando asp.net recibe una solicitud almacenada en caché, Kernel Cache de IIS obtendrá una copia de la misma. Cuando una solicitud proviene de la red, la capa del Kernel recibirá la solicitud. Si la solicitud se almacena en caché, devolverá directamente los datos almacenados en caché y listo. Esto significa que cuando utiliza IIS Kernel Caching para almacenar en caché la salida de la página, obtendrá increíbles mejoras de rendimiento. Al desarrollar asp.net para VS.NET 2005, fui administrador de programas específicamente responsable del rendimiento de asp.net. Mis programadores usaron este método. Miré todos los datos del informe diario y encontré los resultados del uso del almacenamiento en caché del modelo del kernel. lo más rápido. Una característica común de ellos es que las solicitudes y respuestas de la red son grandes, pero IIS sólo ocupa el 5% de los recursos de la CPU. Esto es asombroso. Hay muchas razones para utilizar IIS 6.0, pero el cambio del kernel es la mejor.
9. Comprimir datos con Gzip
A menos que el uso de su CPU sea demasiado alto, es necesario utilizar técnicas para mejorar el rendimiento del servidor. El uso de gzip para comprimir datos puede reducir la cantidad de datos que envía al servidor, mejorar la velocidad de ejecución de la página y también reducir el tráfico de la red. La mejor forma de comprimir los datos depende de los datos que desea enviar y de si el navegador del cliente los admite (IIS envía datos comprimidos con gzip al cliente, y el cliente debe admitir gzip para analizarlos, IE6.0 y Firefox). De esta manera, su servidor puede responder a más solicitudes por segundo. De manera similar, también reduce la cantidad de datos enviados en la respuesta y puede enviar más solicitudes.
Buenas noticias, la compresión gzip se ha integrado en IIS6.0, es mejor que gzip en IIS5.0. Desafortunadamente, para habilitar la compresión gzip en IIS 6.0, no puede configurarla en el cuadro de diálogo de propiedades de IIS 6.0. El equipo de desarrollo de IIS desarrolló la función de compresión gzip, pero se olvidaron de facilitar a los administradores su habilitación en la ventana del administrador. Para habilitar la compresión gzip, solo puede modificar su configuración en el archivo de configuración xml de IIS6.0.
Además de leer este artículo, tengo que leer el artículo <<Compresión IIS6>> escrito por Brad Wilson ( http://www.dotnetdevs.com/articles/IIS6compression.aspx ; también hay un artículo que presenta los conocimientos básicos); de compresión aspx. Habilite la compresión ASPX en IIS. Pero tenga en cuenta que la compresión dinámica y el cambio del kernel son mutuamente excluyentes en IIS6.
10. Ver estado de los controles del servidor
ViewState es una característica de asp.net que se utiliza para guardar un valor de estado utilizado para generar una página en un campo oculto. Cuando la página se vuelve a publicar en el servidor, el servidor analiza, verifica y aplica los datos en ViewState para restaurar el árbol de control de la página. ViewState es una característica muy útil que puede conservar el estado del cliente sin utilizar cookies ni memoria del servidor. La mayoría de los controles de servidor utilizan ViewState para conservar los valores de estado de los elementos que interactúan con el usuario en la página. Por ejemplo, para guardar el número de página de la página actual para paginación.
El uso de ViewState traerá algunos efectos negativos. Primero, aumenta los tiempos de respuesta y solicitud del servidor. En segundo lugar, cada devolución de datos agrega tiempo para serializar y deserializar datos. Finalmente, también consume más memoria en el servidor.
Muchos controles de servidor tienden a utilizar ViewState, como el conocido DataGrid, y en ocasiones no es necesario utilizarlo. ViewState está habilitado de forma predeterminada. Si no desea utilizar ViewState, puede desactivarlo en el nivel de control o de página. En el control, solo necesita establecer la propiedad EnableViewState en False; también puede configurarla en la página para extender su alcance a toda la página:
<%@ Página EnableViewState=”falso” %>
Si la página no requiere una devolución de datos o la página simplemente se representa con controles cada vez que se solicita. Debes desactivar ViewState a nivel de página.
Resumir
Solo proporciono algunos consejos que creo que ayudarán a mejorar la escritura de aplicaciones ASP.NET de alto rendimiento. Los consejos para mejorar el rendimiento de ASP.NET mencionados en este artículo son solo un punto de partida. Para obtener más información, consulte "Mejora de ASP". NET libro "Rendimiento". Sólo a través de tu propia práctica podrás encontrar las técnicas que serán más útiles para tu proyecto. Sin embargo, estos consejos pueden servirle como guía en su viaje de desarrollo. En el desarrollo de software, ninguno de estos es absolutamente útil porque cada proyecto es diferente.
