Es increíble lo fácil que es escribir aplicaciones web usando ASP.NET. Debido a esta simplicidad, muchos desarrolladores no se toman el tiempo para estructurar sus aplicaciones para lograr un mejor rendimiento. En este artículo, cubriré 10 consejos para escribir aplicaciones web de alto rendimiento. Pero no limitaría estas sugerencias a las aplicaciones ASP.NET, ya que estas aplicaciones son sólo parte de una aplicación web. Este artículo no pretende ser una guía definitiva para ajustar el rendimiento de las aplicaciones web; un libro completo no podría cubrir fácilmente este tema. Considere este artículo como un excelente punto de partida.
Antes de convertirme en adicto al trabajo, disfrutaba escalar rocas. Antes de cualquier gran subida, empiezo mirando atentamente las rutas en las guías y leyendo las recomendaciones de visitantes anteriores. Pero no importa qué tan bueno sea el guía, necesitas experiencia real en escalada en roca antes de intentar una escalada particularmente desafiante. De manera similar, sólo puedes aprender a escribir aplicaciones web de alto rendimiento cuando te enfrentas a solucionar problemas de rendimiento o ejecutar un sitio de alto rendimiento.
Mi experiencia personal proviene de trabajar como Gerente de Programas de Infraestructura en la división ASP.NET de Microsoft, donde ejecuté y administré www.ASP.NET y ayudé a diseñar los servidores comunitarios, uno de varios servidores conocidos.
Aplicaciones ASP.NET (foros ASP.NET, .Text y nGallery combinados en una sola plataforma). Estoy seguro de que algunos de los consejos que me ayudaron a mí también te ayudarán a ti.
Debería considerar dividir su aplicación en varias capas lógicas. Es posible que haya escuchado el término arquitectura física de 3 niveles (o n niveles). Por lo general, se trata de enfoques arquitectónicos prescritos que separan físicamente la funcionalidad entre procesos y/o hardware. Cuando el sistema necesita expandirse, se puede agregar fácilmente más hardware. Sin embargo, existe un impacto en el rendimiento asociado con los saltos de proceso y de máquina, y esto debe evitarse. Por lo tanto, si es posible, intente ejecutar páginas ASP.NET y sus componentes relacionados juntos en la misma aplicación.
Debido a la separación del código y los límites entre capas, el uso de servicios web o la comunicación remota degradará el rendimiento en un 20% o más.
La capa de datos es un poco diferente porque normalmente es mejor tener hardware dedicado a la base de datos. Sin embargo, el costo del proceso de saltar a la base de datos sigue siendo alto, por lo que el rendimiento de la capa de datos es el primer tema que debe considerar al optimizar el código.
Antes de profundizar en las correcciones de rendimiento para su aplicación, primero asegúrese de crear un perfil de su aplicación para identificar los problemas específicos. Los contadores clave de rendimiento, como los que representan el porcentaje de tiempo necesario para realizar la recolección de basura, también son útiles para descubrir dónde pasa una aplicación su tiempo principal. Sin embargo, a menudo resulta muy poco intuitivo dónde se invierte el tiempo.
Este artículo describe dos tipos de mejoras de rendimiento: optimizaciones grandes (como el uso del almacenamiento en caché de ASP.NET) y optimizaciones pequeñas que se repiten. Estas pequeñas optimizaciones a veces resultan especialmente interesantes. Haces un pequeño cambio en tu código y ganas muchísimo tiempo. Con grandes optimizaciones, es posible que observe un gran salto en el rendimiento general. Con pequeñas optimizaciones, es posible que solo ahorre unos pocos milisegundos para una solicitud en particular, pero si se suman todas las solicitudes todos los días, puede ser una gran mejora.
Rendimiento de la capa de datos
Cuando se trata de ajustar el rendimiento de la aplicación, existe una prueba con varilla medidora que puede utilizar para priorizar su trabajo: ¿El código accede a la base de datos? Si es así, ¿con qué frecuencia? Tenga en cuenta que esta misma prueba también se puede aplicar al código que utiliza servicios web o comunicación remota, pero este artículo no los cubre.
Si es necesaria una solicitud de base de datos en una ruta de código particular y cree que primero necesita optimizar otras áreas (como la manipulación de cadenas), deténgase y luego realice esta prueba con varilla medidora. Si sus problemas de rendimiento no son graves, es una buena idea dedicar algo de tiempo a optimizar el tiempo invertido en relación con la base de datos, la cantidad de datos que se devuelven y la frecuencia de los viajes de ida y vuelta hacia y desde la base de datos.
Con esta información general en mente, veamos diez consejos que pueden ayudar a mejorar el rendimiento de la aplicación. Primero, hablaré sobre los cambios que podrían marcar la mayor diferencia.
Consejo 1: devolver múltiples conjuntos de resultados
Mire cuidadosamente el código de su base de datos para ver si hay múltiples rutas de solicitud en la base de datos. Cada uno de estos viajes de ida y vuelta reduce la cantidad de solicitudes por segundo que la aplicación puede atender. Al devolver varios conjuntos de resultados en una solicitud de base de datos, puede ahorrar el tiempo total necesario para comunicarse con la base de datos. Al mismo tiempo, también hace que el sistema sea más escalable al reducir el trabajo del servidor de la base de datos en la gestión de solicitudes.
Aunque es posible utilizar SQL dinámico para devolver varios conjuntos de resultados, mi método preferido es utilizar procedimientos almacenados. Existe cierto debate sobre si la lógica de negocios debería residir en el procedimiento almacenado, pero creo que sería mejor si la lógica del procedimiento almacenado pudiera restringir los datos devueltos (reduciendo el tamaño del conjunto de datos, reduciendo el tiempo dedicado a la red, sin tener que examinar los datos de la capa lógica), esto debería favorecerse.
Al completar una clase empresarial fuertemente tipada usando una instancia de SqlCommand y su método ExecuteReader, puede mover el puntero del conjunto de resultados hacia adelante llamando a NextResult. La Figura 1 muestra una sesión de ejemplo que utiliza clases de tipos para completar varias ArrayLists. Devolver solo los datos que necesita de la base de datos reducirá aún más la asignación de memoria en el servidor.
Figura 1 Extracción de múltiples conjuntos de resultados de un DataReader
// lee el primer conjunto de resultados
lector = comando.ExecuteReader();
// lee los datos de ese conjunto de resultados
mientras (lector.Read()) {
proveedores.Add(PopulateSupplierFromIDataReader(lector));
}
// leer el siguiente conjunto de resultados
lector.NextResult();
// lee los datos de ese segundo conjunto de resultados
mientras (lector.Read()) {
productos.Add(PopulateProductFromIDataReader(lector));
}
Consejo 2: acceso a datos paginados
ASP.NET DataGrid tiene una característica interesante: soporte de paginación de datos. Cuando la paginación está habilitada en DataGrid, se muestra una cantidad fija de registros a la vez. Además, se muestra una interfaz de usuario de paginación en la parte inferior del DataGrid para facilitar la navegación entre registros. La interfaz de usuario de paginación le permite navegar hacia adelante y hacia atrás a través de los datos mostrados y muestra una cantidad fija de registros a la vez.
También hay un pequeño giro. La paginación utilizando DataGrid requiere que todos los datos estén vinculados a la cuadrícula. Por ejemplo, si su capa de datos necesita devolver todos los datos, DataGrid filtrará todos los registros mostrados en función de la página actual. Si se devuelven 100.000 registros al paginar a través de DataGrid, se descartan 99.975 registros para cada solicitud (suponiendo un tamaño de página de 25 registros). Cuando aumenta el número de registros, el rendimiento de la aplicación se ve afectado porque se deben enviar más y más datos con cada solicitud.
Una excelente manera de escribir código de paginación con mejor rendimiento es utilizar procedimientos almacenados. La Figura 2 muestra un procedimiento almacenado de ejemplo para paginar la tabla Pedidos en la base de datos Northwind. En resumen, todo lo que tienes que hacer en este punto es pasar el índice de la página y el tamaño de la página. Luego se calcula y devuelve el conjunto de resultados apropiado.
Figura 2 Paginación a través de la tabla de pedidos
CREAR PROCEDIMIENTO northwind_OrdersPagged
(
@PageIndex entero,
@PageSize entero
)
COMO
COMENZAR
DECLARAR @PageLowerBound int
DECLARAR @PageUpperBound int
DECLARE @RowsToReturn int
: primero establezca el recuento de filas
ESTABLECER @RowsToReturn = @PageSize * (@PageIndex + 1)
SET ROWCOUNT @RowsToReturn
: establece los límites de la página
SET @PageLowerBound = @PageSize * @PageIndex
SET @PageUpperBound = @PageLowerBound + @PageSize + 1
- Crea una tabla temporal para almacenar los resultados seleccionados
CREAR TABLA #PageIndex
(
IndexId int IDENTIDAD (1, 1) NO NULO,
ID de pedido int
)
-- Insertar en la tabla temporal
INSERTAR EN #PageIndex (ID de pedido)
SELECCIONAR
ID de pedido
DE
Órdenes
ORDEN POR
OrderID DESC
- Recuento total de devolución
SELECT COUNT(OrderID) FROM Orders
- Devolver resultados paginados
SELECCIONAR
O.*
DE
Órdenes Oh,
#PageIndex Índice de páginas
DÓNDE
O.OrderID = PageIndex.OrderID Y
PageIndex.IndexID > @PageLowerBound Y
PageIndex.IndexID < @PageUpperBound
ORDEN POR
PageIndex.IndexID
FINAL
En el servidor comunitario, escribimos un control de servidor de paginación para completar la paginación de todos los datos. Como verá, estoy usando el concepto analizado en el Consejo 1 para devolver dos conjuntos de resultados de un procedimiento almacenado: el número total de registros y los datos solicitados.
El número total de registros devueltos puede variar según la consulta ejecutada. Por ejemplo, se puede utilizar una cláusula WHERE para restringir los datos devueltos. Para calcular el número total de páginas que se muestran en la interfaz de usuario paginada, debe conocer el número total de registros que se devolverán. Por ejemplo, si hay 1.000.000 de registros en total y desea utilizar una cláusula WHERE para filtrarlos a 1000 registros, la lógica de paginación necesita conocer el número total de registros para poder representar la interfaz de usuario de paginación correctamente.
Consejo 3: agrupación de conexiones
Configurar una conexión TCP entre una aplicación web y SQL Server puede ser una operación que consume muchos recursos. Los desarrolladores de Microsoft han podido utilizar la agrupación de conexiones desde hace algún tiempo, lo que les permite reutilizar las conexiones de bases de datos. En lugar de configurar una nueva conexión TCP para cada solicitud, solo configuran una nueva conexión cuando no hay conexiones en el grupo de conexiones. Cuando se cierra la conexión, regresa al grupo de conexiones donde mantiene la conexión a la base de datos en lugar de destruir la conexión TCP por completo.
Por supuesto, debe tener cuidado si desarrolla conexiones con fugas. Cuando haya terminado de usar sus conexiones, asegúrese de cerrarlas. Para repetir: no importa lo que digan sobre la recolección de basura en Microsoft® .NET Framework, asegúrese de llamar explícitamente a Cerrar o Disponer en una conexión cuando haya terminado de usarla. No confíe en que Common Language Runtime (CLR) borre y cierre conexiones en momentos predeterminados. Aunque CLR eventualmente destruirá la clase y forzará el cierre de la conexión, no hay garantía de cuándo ocurre realmente la recolección de basura del objeto.
Para utilizar la agrupación de conexiones de forma óptima, se deben seguir algunas reglas. Primero abra la conexión, realice la operación y luego cierre la conexión. Si es necesario, abra y cierre la conexión varias veces por solicitud (preferiblemente aplicando el consejo 1), pero no mantenga la conexión abierta todo el tiempo ni la pase dentro y fuera usando varios métodos diferentes. En segundo lugar, utilice la misma cadena de conexión (y el mismo ID de hilo si utiliza la autenticación integrada). Si no utiliza la misma cadena de conexión, por ejemplo, si personaliza la cadena de conexión según el usuario que inició sesión, no obtendrá el mismo valor de optimización que proporciona el grupo de conexiones. Si utiliza la autenticación integrada y también se hace pasar por una gran cantidad de usuarios, la eficiencia del grupo de conexiones también disminuirá significativamente. Los contadores de rendimiento de datos .NET CLR pueden resultar útiles al intentar localizar cualquier problema de rendimiento relacionado con la agrupación de conexiones.
Siempre que su aplicación se conecta a un recurso, como una base de datos que se ejecuta en otro proceso, debe optimizar centrándose en el tiempo que lleva conectarse a ese recurso, el tiempo que lleva enviar o recuperar datos y la cantidad de viajes de ida y vuelta. Optimizar cualquier tipo de salto de proceso en su aplicación es el primer punto para obtener un mejor rendimiento.
La capa de aplicación contiene la lógica para conectarse a la capa de datos y transformar los datos en instancias de clase y procesos comerciales significativos. Por ejemplo, un servidor comunitario, donde desea completar la colección Foros o Hilos, aplicar reglas comerciales (como permisos y, lo más importante, ejecutar allí la lógica de almacenamiento en caché);
Consejo 4: API de almacenamiento en caché de ASP.NET
Antes de escribir una línea de código de aplicación, una de las primeras cosas que debe hacer es estructurar la capa de aplicación para aprovechar al máximo las capacidades de almacenamiento en caché de ASP.NET.
Si su componente se va a ejecutar en una aplicación ASP.NET, solo necesita incluir una referencia a System.Web.dll en el proyecto de la aplicación. Cuando necesite acceder al caché, use la propiedad HttpRuntime.Cache (también se puede acceder a este objeto a través de Page.Cache y HttpContext.Cache).
Existen varias reglas para almacenar datos en caché. En primer lugar, si es probable que los datos se utilicen varias veces, esta es una buena alternativa al uso del almacenamiento en caché. En segundo lugar, si los datos son genéricos y no específicos de una solicitud o usuario específico, también es un buen candidato para el almacenamiento en caché. Si los datos son específicos del usuario o de la solicitud, pero tienen una vida útil prolongada, aún se pueden almacenar en caché, pero es posible que no se utilicen con mucha frecuencia. En tercer lugar, una regla que a menudo se pasa por alto es que a veces se puede almacenar en caché demasiado. Normalmente, en una computadora x86, para reducir la posibilidad de errores de falta de memoria, querrás ejecutar procesos con no más de 800 MB de bytes privados. Por lo tanto el caché debería tener un límite. En otras palabras, es posible que pueda reutilizar el resultado de un cálculo, pero si ese cálculo requiere 10 parámetros, es posible que esté intentando almacenar en caché 10 permutaciones, lo que podría causarle problemas. Una de las solicitudes más comunes de compatibilidad con ASP.NET son los errores de falta de memoria causados por un almacenamiento en caché excesivo, especialmente para conjuntos de datos grandes.
El almacenamiento en caché tiene varias características excelentes que debes conocer. Primero, el caché implementa un algoritmo usado menos recientemente, lo que permite a ASP.NET forzar la purga del caché (eliminando automáticamente los elementos no utilizados del caché) cuando la memoria se ejecuta de manera menos eficiente. En segundo lugar, la caché admite dependencias caducadas que se pueden forzar a caducar. Estas dependencias incluyen tiempo, claves y archivos. A menudo se utiliza el tiempo, pero con ASP.NET 2.0, se introduce un tipo de invalidación nuevo y más potente: la invalidación de la caché de la base de datos. Se refiere a eliminar automáticamente elementos en el caché cuando cambian los datos en la base de datos. Para obtener más información sobre la invalidación de la memoria caché de la base de datos, consulte la columna Dino Esposito Cutting Edge en la revista MSDN de julio de 2004. Para comprender la arquitectura del caché, consulte el siguiente diagrama.
 |
Consejo 6: procesamiento en segundo plano
El camino hacia el código debería ser lo más rápido posible, ¿verdad? Puede haber ocasiones en las que sienta que una tarea que se realiza en cada solicitud o una vez cada n solicitudes requiere muchos recursos. Enviar correos electrónicos o analizar y validar datos entrantes son algunos ejemplos.
Al analizar los foros ASP.NET 1.0 y rediseñar el contenido que conforma el servidor comunitario, descubrimos que agregar nuevas rutas de código de publicación era muy lento. Cada vez que se agrega una nueva publicación, la aplicación primero debe asegurarse de que no haya publicaciones duplicadas, luego debe analizar la publicación usando un filtro de "malas palabras", analizar el emoticón del personaje publicado, etiquetar e indexar la publicación y agregar el publicar cuando se solicite Vaya a la cola correspondiente, valide el archivo adjunto y, tras la publicación final, envíe una notificación por correo electrónico a todos los suscriptores de inmediato. Claramente, hay mucho involucrado.
Después de la investigación, se descubrió que la mayor parte del tiempo se dedicaba a indexar la lógica y enviar correos electrónicos. Indexar publicaciones es una operación que requiere mucho tiempo y se descubrió que la funcionalidad integrada System.Web.Mail se conecta a un servidor SMYP y luego envía correos electrónicos continuamente. A medida que aumenta el número de suscriptores de una publicación o área temática en particular, la función AddPost tarda cada vez más en ejecutarse.
No se requiere la indexación de correo electrónico para todas las solicitudes. Idealmente, nos gustaría realizar esta operación por lotes, indexando 25 publicaciones a la vez o enviando todos los correos electrónicos cada cinco minutos. Decidimos usar código que habíamos usado previamente para crear un prototipo de invalidación de caché de datos que se usó para lo que terminó en Visual Studio® 2005.
La clase Timer en el espacio de nombres System.Threading es muy útil, pero no muy conocida en .NET Framework, al menos entre los desarrolladores web. Una vez creada, esta clase Timer llamará a la devolución de llamada especificada en un intervalo configurable para un subproceso en ThreadPool. Esto significa que puede configurar su código para que se ejecute sin solicitudes entrantes a la aplicación ASP.NET, lo cual es ideal para el procesamiento en segundo plano. También puede realizar operaciones como indexar o enviar correos electrónicos en este proceso en segundo plano.
Sin embargo, existen varios problemas con esta tecnología. Si se desinstala el dominio de la aplicación, esta instancia del temporizador dejará de activar sus eventos. Además, debido a que CLR tiene un estándar estricto para la cantidad de subprocesos por proceso, puede haber situaciones en las que el servidor esté muy cargado y el temporizador no tenga subprocesos para completar, lo que provocará retrasos en cierta medida. ASP.NET intenta minimizar la posibilidad de que esto suceda manteniendo una cierta cantidad de subprocesos disponibles en el proceso y utilizando solo una parte del total de subprocesos para el procesamiento de solicitudes. Sin embargo, esto puede ser un problema si tiene muchas operaciones asincrónicas.
No hay suficiente espacio aquí para este código, pero puede descargar un ejemplo legible en www.rob-howard.net. Vea las diapositivas y demostraciones de la presentación Blackbelt TechEd 2004.
Consejo 7: almacenamiento en caché de resultados de página y servidores proxy
ASP.NET es su capa de presentación (o debería ser su capa de presentación); consta de 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 resultados (HTML, XML, imágenes o cualquier otro dato) y cuando ejecuta este código en cada solicitud, genera el mismo resultado, entonces tiene una herramienta que puede usarse para A. Gran alternativa al almacenamiento en caché de resultados de páginas.
Agregue esta línea de contenido a la parte superior de la página <%@ Page OutputCache VaryByParams="none" Duration="60" %>
Puede generar de manera eficiente el resultado para esta página una vez y luego reutilizarlo varias veces durante hasta 60 segundos, momento en el cual la página se volverá a ejecutar y el resultado se agregará nuevamente al caché de ASP.NET. Este comportamiento también se puede lograr utilizando algunas API programáticas de bajo nivel. Hay varias opciones configurables para el almacenamiento en caché de resultados, como la propiedad VaryByParams que acabamos de mencionar. VaryByParams solo se solicita, pero también le permite especificar parámetros HTTP GET o HTTP POST para cambiar las entradas de la caché. Por ejemplo, simplemente configure VaryByParam="Report" para almacenar en caché la salida para default.aspx?Report=1 o default.aspx?Report=2. Se pueden especificar parámetros adicionales especificando una lista separada por punto y coma.
Mucha gente no sabe que cuando se utiliza el almacenamiento en caché de resultados, las páginas ASP.NET también generan algunos encabezados HTTP que se encuentran en el nivel inferior del servidor de almacenamiento en caché, como los utilizados por Microsoft Internet Security and Acceleration Server o Akamai. Después de configurar el encabezado de caché HTTP, los documentos se pueden almacenar en caché en estos recursos de red y las solicitudes de los clientes se pueden satisfacer sin regresar al servidor de origen.
Por lo tanto, el uso del almacenamiento en caché de salida de página no hará que su aplicación sea más eficiente, pero puede reducir la carga en el servidor porque las tecnologías de almacenamiento en caché posteriores almacenan en caché el documento. Por supuesto, esto podría ser simplemente contenido anónimo; una vez que se descarga, nunca volverá a ver esas solicitudes y ya no podrá realizar la autenticación para evitar el acceso a él.
Consejo 8: ejecute IIS 6.0 (solo utilícelo para el almacenamiento en caché del kernel)
Si no está ejecutando IIS 6.0 (¿Windows Server? 2003), se está perdiendo algunas grandes mejoras de rendimiento en los servidores web de Microsoft. En el consejo 7, hablé del almacenamiento en caché de resultados. En IIS 5.0, las solicitudes pasan por IIS y luego por ASP.NET. Cuando se trata de almacenamiento en caché, HttpModule en ASP.NET recibe la solicitud y devuelve el contenido del caché.
Si está utilizando IIS 6.0, encontrará una pequeña característica llamada caché del kernel que no requiere ningún cambio de código en ASP.NET. Cuando ASP.NET realiza una solicitud de almacenamiento en caché de resultados, el caché del kernel de IIS recibe una copia de los datos almacenados en caché. Cuando una solicitud proviene de un controlador de red, el controlador a nivel de kernel (sin cambio de contexto al modo de usuario) recibe la solicitud, vacía los datos almacenados en caché en la respuesta, si está en caché, y luego completa la ejecución. Esto significa que cuando utilice el almacenamiento en caché en modo kernel con el almacenamiento en caché de salida de IIS y ASP.NET, verá resultados de rendimiento increíbles. Durante el desarrollo de ASP.NET en Visual Studio 2005, fui el administrador del programa responsable del rendimiento de ASP.NET. Los desarrolladores hacen el trabajo específico, pero yo puedo ver todos los informes que se generan todos los días. Los resultados de la caché en modo kernel son siempre los más interesantes. La característica más común es que la red está inundada de solicitudes/respuestas, mientras que IIS se ejecuta con solo un 5 % de uso de CPU. ¡Esto es impactante! Por supuesto, existen otras razones para utilizar IIS 6.0, pero el almacenamiento en caché en modo kernel es la más obvia.
Consejo 9: utilice la compresión Gzip
Aunque usar gzip no es necesariamente un truco para el rendimiento del servidor (ya que puede ver un aumento en el uso de la CPU), el uso de la compresión gzip puede reducir la cantidad de bytes enviados por el servidor. Esto da como resultado un aumento percibido en la velocidad de la página y un uso reducido del ancho de banda. Dependiendo de los datos que se envían, de cuánto se pueden comprimir y de si el navegador del cliente los admite (IIS solo enviará contenido comprimido con gzip a clientes que admitan la compresión gzip, como Internet Explorer 6.0 y Firefox), su servidor puede servir Más solicitudes. De hecho, casi cada vez que reduce la cantidad de datos devueltos, aumenta la cantidad de solicitudes por segundo.
La compresión gzip está integrada en IIS 6.0 y su rendimiento es mucho mejor que la compresión gzip utilizada en IIS 5.0, lo cual es una buena noticia. Desafortunadamente, al intentar activar la compresión gzip en IIS 6.0, es posible que no pueda encontrar la configuración en el cuadro de diálogo Propiedades de IIS. El equipo de IIS incorporó una excelente funcionalidad gzip al servidor, pero olvidó incluir una interfaz de usuario administrativa para habilitarla. Para habilitar la compresión gzip, debe profundizar en los ajustes de configuración XML de IIS 6.0 (para que no se debilite). Por cierto, el crédito es para Scott Forsyth de OrcsWeb por ayudarme a plantear este problema con el servidor www.asp.net alojado en OrcsWeb.
Este artículo no describirá los pasos. Lea el artículo de Brad Wilson en Compresión IIS6. También hay un artículo de la base de conocimientos sobre cómo habilitar la compresión para ASPX en Habilitar compresión ASPX en IIS. Sin embargo, debe tener en cuenta que, debido a algunos detalles de implementación, la compresión dinámica y el almacenamiento en caché del kernel no pueden existir simultáneamente en IIS 6.0.
Consejo 10: Estado de la vista de control del servidor
Ver estado es un nombre interesante para ASP.NET que almacena algunos datos de estado en campos de salida ocultos de la página generada. Cuando la página se vuelve a publicar en el servidor, el servidor puede analizar, validar y aplicar estos datos de estado de vista al árbol de control de la página. Ver estado es una característica muy poderosa porque permite que el estado persista en el cliente y no requiere cookies ni memoria del servidor para guardar este estado. Muchos controles de servidor ASP.NET utilizan el estado de vista para conservar la configuración creada durante las interacciones con elementos de la página, como guardar la página actual que se muestra al paginar datos.
Sin embargo, utilizar el estado de vista también tiene algunas desventajas. En primer lugar, aumenta la carga general de la página cada vez que se publica o solicita. También se produce una sobrecarga adicional al serializar o deserializar los datos del estado de la vista publicados en el servidor. Finalmente, el estado de vista aumenta la asignación de memoria en el servidor.
Varios controles de servidor tienden a abusar del estado de vista incluso cuando no es necesario, el más famoso de los cuales es DataGrid. El comportamiento predeterminado de la propiedad ViewState está activado, pero puede desactivarlo en el nivel de control o de página si no lo necesita. Dentro del control, simplemente establezca la propiedad EnableViewState en falso o configúrela globalmente en la página usando la siguiente configuración:
＜%@ Página EnableViewState="false" %＞
Si no vuelve a publicar la página o siempre regenera los controles de la página en cada solicitud, debe desactivar el estado de visualización a nivel de página.
Le he dado algunos consejos que encuentro útiles al escribir aplicaciones ASP.NET de alto rendimiento. Como mencioné anteriormente en este artículo, esta es una guía preliminar y no la última palabra sobre el rendimiento de ASP.NET. (Para obtener información sobre cómo mejorar el rendimiento de la aplicación ASP.NET, consulte Mejora del rendimiento de ASP.NET). La mejor manera de resolver un problema de rendimiento específico solo puede encontrarse a través de su propia experiencia. Sin embargo, estos consejos deberían brindarle una buena orientación en su viaje. En el desarrollo de software, existen pocos absolutos; cada aplicación es única.