Desarrollar aplicaciones ASP.NET de alto rendimiento

  • Artículo

En las instrucciones de este tema se incluyen técnicas que pueden ayudar a maximizar el rendimiento de las aplicaciones Web ASP.NET. Las instrucciones se dividen en las secciones siguientes:

  • Procesamiento de páginas y controles de servidor

  • Administración del estado

  • Acceso a datos

  • Aplicaciones Web

  • Prácticas de codificación

Procesamiento de páginas y controles de servidor

Las instrucciones siguientes sugieren formas de trabajar eficazmente con páginas y controles ASP.NET.

  • Evite las acciones de ida y vuelta innecesarias en el servidor Hay circunstancias en las que no es necesario utilizar los controles de servidor ASP.NET ni controlar los eventos de devolución de datos. Por ejemplo, a menudo la validación de los datos proporcionados por el usuario en las páginas Web ASP.NET puede tener lugar en el cliente antes de enviar los datos al servidor. Por lo general, si no es necesario retransmitir información al servidor para comprobarla o para escribirla en un almacén de datos, se puede mejorar el rendimiento de la página y la experiencia del usuario si no se utiliza código que produzca acciones de ida y vuelta en el servidor. También puede utilizar devoluciones de llamada de cliente para leer los datos del servidor en lugar de realizar una acción de ida y vuelta completa. Para obtener información detallada, vea Implementar devoluciones de llamada de cliente sin devoluciones de datos en las páginas Web ASP.NET.

    Si desarrolla controles de servidor personalizados, considere la posibilidad de hacer que representen código de cliente cuando el explorador sea compatible con ECMAScript (JavaScript). Si los controles de servidor se utilizan de este modo, es posible reducir drásticamente el número de veces que la información se envía al servidor Web. Para obtener más información, vea Desarrollar controles de servidor ASP.NET personalizados.

  • Use la propiedad IsPostBack del objeto Page para evitar procesamientos innecesarios en acciones de ida y vuelta Si escribe código que controla el procesamiento de la devolución de datos de los controles de servidor, en ocasiones deseará que el código se ejecute sólo la primera vez que se solicite la página en lugar de en cada devolución de datos. Utilice la propiedad IsPostBack para ejecutar el código condicionalmente en función de si la página se genera como respuesta a un evento de control de servidor.

  • Guarde el estado de vista del control de servidor sólo cuando sea necesario La administración automática del estado de vista permite que los controles de servidor vuelvan a rellenar los valores de sus propiedades en una acción de ida y vuelta sin que sea necesario escribir código. Sin embargo, esta característica afecta al rendimiento, ya que el estado de vista de un control de servidor se pasa hacia y desde el servidor en un campo de formulario oculto. Resulta útil saber en qué circunstancias el estado de vista ayuda y cuándo obstaculiza el rendimiento de la página. Por ejemplo, si va a enlazar un control de servidor a datos en cada acción de ida y vuelta, el estado de vista guardado no es útil, porque los valores del control se reemplazan con nuevos valores durante el enlace de datos. En ese caso, si deshabilita el estado de vista, reducirá el tiempo de procesamiento y el tamaño de la página.

    De forma predeterminada, el estado de vista está habilitado para todos los controles de servidor. Para deshabilitarlo, establezca la propiedad EnableViewState de control en false, como en el siguiente ejemplo de control de servidor DataGrid:

    <asp:datagrid EnableViewState="false" datasource="..." 
   runat="server"/>

    También puede deshabilitar el estado de vista de una página completa con la directiva @ Page. Esto resulta útil cuando no se responde al servidor desde una página:

    <%@ Page EnableViewState="false" %>

    Nota

    El atributo EnableViewState también se admite en la directiva @ Control para especificar si el estado de vista se habilita para un control de usuario.

    Para analizar el tamaño del estado de vista utilizado por los controles de servidor de una página, habilite el seguimiento para la página incluyendo el atributo trace="true" en la directiva @ Page. En el resultado de seguimiento, observe la columna Viewstate de la tabla Control Hierarchy. Para obtener información acerca del seguimiento y cómo habilitarlo, vea Seguimiento en ASP.NET.

  • Mantenga el almacenamiento en búfer activado a menos que tenga razones para desactivarlo Deshabilitar el almacenamiento en búfer de las páginas Web ASP.NET representa un costo de rendimiento significativo. Para obtener más información, vea la propiedad Buffer.

  • Utilice la clase Transfer de Server o el envío entre páginas para habilitar el redireccionamiento entre las páginas ASP.NET de una misma aplicación Para obtener información detallada, vea Redirigir a los usuarios a otra página.

Administración del estado

En las instrucciones siguientes encontrará sugerencias para que la administración de estado sea eficaz.

  • Deshabilite el estado de sesión cuando no lo utilice No todas las aplicaciones o páginas requieren el estado de sesión por usuario; debería deshabilitar el estado de sesión si no es necesario. Para deshabilitar el estado de sesión de una página, establezca el atributo EnableSessionState de la directiva @ Page en el valor false, tal como se muestra en el ejemplo siguiente:

    <%@ Page EnableSessionState="false" %>

    Nota

    Si una página requiere acceso a las variables de sesión pero no va a crearlas ni modificarlas, establezca el atributo EnableSessionState de la directiva @ Page en ReadOnly.

    También se puede deshabilitar el estado de sesión para los métodos de servicio Web XML. Para obtener más información, vea Servicios Web XML creados mediante clientes de servicios Web ASP.NET y XML.

    Para deshabilitar el estado de sesión para una aplicación, establezca el atributo Mode en Off en la sección SessionState del archivo Web.config de la aplicación, como en el ejemplo siguiente:

    <sessionState mode="Off" />

  • Elija el proveedor de estado de sesión adecuado para las necesidades de la aplicación ASP.NET proporciona varias maneras de almacenar los datos de sesión de una aplicación: estado de sesión en proceso, estado de sesión fuera de proceso como un servicio de Windows y estado de sesión fuera de proceso en una base de datos de SQL Server. (También puede crear un proveedor de estado de sesión personalizado para almacenar los datos de sesión en un almacén de datos de su elección.) Cada opción tiene sus ventajas, pero el estado de sesión en proceso es, con diferencia, la solución más rápida. Si sólo va a almacenar pequeñas cantidades de datos variables en el estado de sesión, se recomienda utilizar el proveedor en proceso. Las opciones de estado de sesión fuera de proceso son útiles si va a escalar la aplicación entre varios procesadores o varios equipos, o si desea mantener los datos de sesión si se reinicia un servidor o un proceso. Para obtener más información, vea Estado de sesión de ASP.NET.

Acceso a datos

En las instrucciones siguientes se ofrecen sugerencias para que el acceso a los datos en la aplicación sea eficaz.

  • Use SQL Server y procedimientos almacenados para el acceso a los datos De todos los métodos de acceso a datos suministrados por .NET Framework, la opción recomendada para crear aplicaciones Web escalables y de alto rendimiento es usar SQL Server para el acceso a los datos. Si utiliza el proveedor SQL Server administrado, el rendimiento mejorará aún más si emplea, siempre que sea posible, procedimientos almacenados compilados en lugar de comandos SQL. Para obtener información sobre cómo utilizar los procedimientos almacenados de SQL Server, vea Utilizar procedimientos almacenados con un comando.

  • Utilice la clase SqlDataReader para los cursores de datos de sólo avance rápido La clase SqlDataReader proporciona una secuencia de datos de sólo avance recuperada de una base de datos de SQL Server. Si puede utilizar una secuencia de sólo lectura en la aplicación ASP.NET, la clase SqlDataReader proporciona un mayor rendimiento que la clase DataSet. La clase SqlDataReader utiliza el formato de transferencia de datos de red nativo de SQL Server para leer los datos directamente de una conexión de base de datos. Por ejemplo, al enlazar con el control SqlDataSource, obtendrá un mayor rendimiento si establece la propiedad DataSourceMode en DataReader. (Cuando se utiliza un lector de datos, se pierde funcionalidad.) Además, la clase SqlDataReader implementa la interfaz IEnumerable, que también permite enlazar los datos a controles de servidor. Para obtener más información, vea la clase SqlDataReader. Para obtener información sobre el modo en que ASP.NET tiene acceso a los datos, vea Obtener acceso a datos con ASP.NET.

  • Almacene en caché los datos y los resultados de página siempre que sea posible ASP.NET ofrece mecanismos para almacenar en caché los resultados de página o datos cuando no tienen que calcularse dinámicamente para cada solicitud de página. Además, el diseño de las solicitudes de páginas y de datos que puedan almacenarse en caché, especialmente en las áreas del sitio en las que se espere mayor tráfico, puede optimizar el rendimiento de las páginas. Si utiliza la caché correctamente, el rendimiento de su sitio mejorará más que si utiliza cualquier otra característica de .NET Framework.

    Al utilizar el almacenamiento en caché de ASP.NET, tenga en cuenta los siguientes extremos. En primer lugar, no almacene en caché demasiados elementos. Hay un costo de memoria por almacenar en memoria caché cada elemento. Los elementos que se vuelven a calcular fácilmente, o que rara vez se utilizan, no se deben almacenar en caché. En segundo lugar, no asigne a los elementos almacenados en caché un período de caducidad corto. Los elementos que caducan rápidamente provocan una renovación innecesaria de la caché y pueden generar más trabajo para el código de limpieza y el recolector de elementos no utilizados. Para controlar la renovación de la caché debida a la caducidad de los elementos utilice el contador de rendimiento Tasa de renovación total de caché asociado al objeto de rendimiento Aplicaciones ASP.NET. Una tasa alta de renovación puede indicar la existencia de un problema, especialmente si los elementos se quitan antes de que caduquen. (Esta situación en ocasiones se denomina necesidad de memoria.)

    Para obtener información sobre cómo almacenar en caché los resultados de página y las solicitudes de datos, vea Información general sobre el almacenamiento en caché en ASP.NET.

  • **Utilice la dependencia de caché de SQL de manera apropiada **ASP.NET admite el sondeo basado en tabla y la notificación de consulta, según la versión de SQL Server que se utilice. Todas las versiones de SQL Server admiten el sondeo basado en tabla. En el caso de este tipo de sondeo, si cambia algo en una tabla, se invalidan todos los agentes de escucha. Esto puede generar una renovación de código innecesaria en la aplicación. El sondeo basado en tabla no se recomienda para las tablas que cambian con gran frecuencia. Por ejemplo, el sondeo basado en tabla sería recomendable para una tabla de catálogos, que no cambia con frecuencia. No se recomienda para una tabla de pedidos, que se actualiza con mayor frecuencia. SQL Server 2005 admite la notificación de consulta que, a su vez, admite consultas específicas, por lo que se reduce el número de notificaciones que se envían al cambiarse una tabla. Su rendimiento es mejor que el del sondeo basado en tabla y no genera miles de consultas.

    Para obtener más información sobre la dependencia de caché de SQL, vea Tutorial: Utilizar el almacenamiento en la caché de resultados de ASP.NET con SQL Server o Almacenar en caché en ASP.NET con la clase SqlCacheDependency.

  • Utilice la paginación y ordenación del origen de datos en lugar de utilizar la paginación y ordenación de la interfaz de usuario (UI) La característica de paginación de UI de los controles de datos como DetailsView y GridView puede utilizarse con cualquier objeto de origen de datos que admita la interfaz ICollection. Para cada operación de paginación, el control de datos pide al origen de datos toda la colección de datos, selecciona las filas que se van a mostrar y descarta los datos restantes. Si un origen de datos implementa DataSourceView y la propiedad CanPage devuelve true, el control de datos utilizará la paginación del origen de datos en lugar de la paginación de la UI. En ese caso, el control de datos pedirá sólo la fila necesaria para cada operación de paginación. Por consiguiente, la paginación del origen de datos es más eficaz que la paginación de la UI. Sólo el control de origen de datos ObjectDataSource admite la paginación del origen de datos. Para habilitar la paginación del origen de datos en otros controles de origen de datos, debe heredar del control de origen de datos y modificar su comportamiento.

  • Sopese la ventaja de la validación de eventos en términos de seguridad y su costo para el rendimiento Los controles que se deriven de las clases System.Web.UI.WebControls y System.Web.UI.HtmlControls pueden validar que un evento originado desde la interfaz de usuario es representado por el control. Esto ayuda a evitar que el control responda a una notificación de eventos suplantada. Por ejemplo, el control DetailsView puede evitar que se procese una llamada a Delete (que el control no admite de manera inherente) y que se eliminen los datos. Esta validación tiene un costo para el rendimiento. Puede controlar este comportamiento mediante el elemento de configuración EnableEventValidation y el método RegisterForEventValidation. El costo de validación depende del número de controles en la página y tiene un intervalo de unos porcentajes.

    Security noteNota de seguridad

    Se recomienda no deshabilitar la validación de eventos. Antes de deshabilitarla, debe estar seguro de que no se puede construir ninguna devolución de datos que tenga un efecto no deseado en la aplicación.

  • Evite el cifrado del estado de vista, a menos que sea necesario El cifrado del estado de vista impide que los usuarios puedan leer los valores en el campo de estado de vista oculto. Un caso típico es un control GridView con un campo de identificador en la propiedad DataKeyNames. El campo de identificador es necesario para coordinar las actualizaciones de los registros. Dado que los usuarios no pueden ver el identificador, puede cifrar el estado de vista. Sin embargo, el cifrado tiene un costo constante para el rendimiento de la inicialización así como un costo adicional que depende del tamaño del estado de vista que se cifre. El cifrado se configura para cada carga de página, por lo que se produce el mismo efecto de rendimiento cada vez que se carga una página.

  • Utilice el almacenamiento en caché, la ordenación y el filtrado de SqlDataSource Si la propiedad DataSourceMode del control SqlDataSource tiene el valor DataSet, SqlDataSource puede almacenar en caché el conjunto de resultados de una consulta. Si los datos se almacenan de esta manera en la memoria caché, las opciones de filtrado y ordenación del control (configuradas con las propiedades FilterExpression y SortParameterName) utilizan los datos almacenados en caché. En muchos casos, la aplicación se ejecutará con mayor rapidez si se almacena el conjunto de datos completo en la memoria caché y se utilizan las propiedades FilterExpression y SortParameterName para ordenar y filtrar, en lugar de utilizar las consultas SQL con cláusulas "WHERE" y "SORT BY" que obtienen acceso a la base de datos para cada acción de selección.

Aplicaciones Web

En las instrucciones siguientes se ofrecen sugerencias para que el conjunto de aplicaciones Web funcione eficazmente.

  • Considere la precompilación Una aplicación Web se compila por lotes en la primera solicitud de un recurso, como una página Web ASP.NET. Si no se ha compilado ninguna página de la aplicación, la compilación por lotes compila todas las páginas de un directorio en fragmentos para mejorar el uso del disco y de la memoria. Puede utilizar la Herramienta de compilación de ASP.NET (Aspnet_compiler.exe) para precompilar una aplicación Web. Para la compilación en contexto, la herramienta de compilación llama al motor en tiempo de ejecución de ASP.NET para que compile el sitio de la misma manera que cuando un usuario solicita una página del sitio Web. Puede precompilar una aplicación Web para que se conserve el marcado de UI o puede precompilar las páginas para que no se pueda cambiar el código fuente. Para obtener más información, vea How to: Precompile ASP.NET Web SitesCómo: Precompilar sitios Web ASP.NET.

  • Ejecute las aplicaciones Web fuera de proceso en Servicios de Internet Information Server 5.0. De manera predeterminada, ASP.NET en IIS 5.0 atenderá las solicitudes mediante un proceso de trabajo fuera de proceso. Esta característica se ha ajustado para un mayor rendimiento. Debido a sus características y ventajas, se recomienda ejecutar ASP.NET en un proceso de trabajo fuera de proceso para sitios de producción.

  • Recicle los procesos periódicamente. Los procesos deben reciclarse periódicamente, tanto por motivos de estabilidad como por motivos de rendimiento. A largo plazo, los recursos con errores y pérdidas de memoria pueden afectar al rendimiento del servidor Web y el reciclaje de los procesos evita que la memoria tenga este tipo de problemas. Sin embargo, debería pensar si sería suficiente reciclar periódicamente, porque es posible que las ventajas del reciclaje no compensen el costo que representa detener el proceso de trabajo, volver a cargar las páginas y volver a obtener los recursos y datos.

    Las aplicaciones Web ASP.NET que se ejecutan en Windows Server 2003, que utiliza IIS 6.0, no necesitan que se ajuste la configuración del modelo de proceso, porque, en este caso, ASP.NET utiliza la configuración de modelo de proceso de IIS 6.0.

  • Si es necesario, ajuste el número de subprocesos por proceso de trabajo de la aplicación La arquitectura de solicitud de ASP.NET intenta obtener un equilibrio entre el número de subprocesos que ejecutan las solicitudes y los recursos disponibles. Esta arquitectura permite que se ejecuten al mismo tiempo únicamente las solicitudes que admita la capacidad disponible de la CPU. Esta técnica se conoce como control de subprocesos. No obstante, hay situaciones en las que el algoritmo de control de subprocesos no funciona bien. El control de subprocesos se puede supervisar en el monitor de rendimiento de Windows a través del contador de rendimiento Recuento de instancias de canalización asociado al objeto de rendimiento Aplicaciones ASP.NET.

    Cuando una página Web ASP.NET llama a un recurso externo, por ejemplo, al realizar solicitudes de acceso a bases de datos o solicitudes de servicios Web XML, por lo general, la solicitud de la página se detiene hasta que el recurso externo responde, liberando la CPU para que procese otros subprocesos. Si otra solicitud está en espera de ser procesada y se libera un subproceso del grupo de subprocesos, empieza a procesarse la solicitud en espera. En consecuencia, habrá un gran número de solicitudes ejecutándose simultáneamente y muchos subprocesos en espera en el proceso de trabajo o grupo de aplicaciones de ASP.NET, lo que afectará negativamente a la productividad del servidor Web y, por tanto, al rendimiento.

    Para mitigar esta situación, se puede establecer manualmente un límite para el número de subprocesos del proceso, cambiando los atributos MaxWorkerThreads y MaxIOThreads en la sección processModel del archivo Machine.config.

    Nota

    Los subprocesos de trabajo se utilizan para procesar solicitudes ASP.NET, mientras que los subprocesos de E/S se utilizan para administrar datos de archivos, bases de datos o servicios Web XML.

    Los valores que se asignan a los atributos del modelo de proceso son el número máximo de cada tipo de subproceso por CPU en el proceso. En un equipo con dos procesadores, el número máximo es dos veces el valor predeterminado. Para los equipos que tengan cuatro procesadores, el número máximo es 4 veces el valor establecido. Los valores predeterminados son correctos para equipos con uno o dos procesadores, pero que el proceso tenga 100 ó 200 subprocesos en equipos con más de dos procesadores puede ser más perjudicial que ventajoso para el rendimiento. Demasiados subprocesos en un proceso tienden a ralentizar el servidor debido a que los cambios de contexto adicionales hacen que el sistema operativo consuma ciclos de la CPU en mantener los subprocesos, en vez de en procesar solicitudes. El número adecuado de subprocesos se determina mejor comprobando el rendimiento de la aplicación.

  • Si las aplicaciones se basan en gran medida en recursos externos, piense en habilitar una matriz de procesos Web en los equipos multiprocesador El modelo de proceso de ASP.NET ayuda a habilitar la escalabilidad en los equipos con varios procesadores distribuyendo el trabajo entre varios procesos, uno por CPU, cada uno con una afinidad del procesador establecida en una CPU. Esta técnica se denomina matriz de procesos Web. Si una aplicación utiliza un servidor de bases de datos lento o llama a objetos COM con dependencias externas, por mencionar sólo dos posibilidades, puede resultar ventajoso habilitar una matriz de procesos Web para la aplicación. Sin embargo, antes de habilitarla para un sitio Web de producción, debería comprobar el funcionamiento de la aplicación con el hospedaje multiproceso en un único equipo.

  • Deshabilite el modo de depuración Deshabilite siempre el modo de depuración antes de implementar una aplicación de producción o realizar cualquier medida del rendimiento. Si el modo de depuración está habilitado, el rendimiento de la aplicación puede verse afectado. Para obtener información acerca de la sintaxis para establecer el modo de depuración, vea Editar los archivos de configuración de ASP.NET.

  • Ajuste a sus necesidades los archivos de configuración del servidor Web y de aplicaciones específicas De manera predeterminada, la configuración de ASP.NET está definida para ofrecer el conjunto más amplio de características y para intentar ajustarse a los escenarios más comunes. Algunos de los valores de configuración predeterminados se pueden cambiar para mejorar el rendimiento de las aplicaciones, dependiendo de las características que se utilicen. La lista siguiente incluye valores de configuración que debería considerar:

    • Habilite la autenticación sólo para las aplicaciones que la necesiten De manera predeterminada, el modo de autenticación de las aplicaciones ASP.NET es la autenticación de Windows o NTLM integrada. En la mayoría de los casos conviene deshabilitar la autenticación en el archivo Machine.config y habilitarla en los archivos Web.config de las aplicaciones que la necesiten.

    • Configure la aplicación con los valores correctos de codificación de solicitudes y respuestas La codificación predeterminada de ASP.NET es UTF-8. Si la aplicación utiliza únicamente caracteres ASCII, configúrela para ASCII y obtendrá una ligera mejora del rendimiento.

    • Piense en deshabilitar AutoEventWireup para la aplicación Si se establece el atributo AutoEventWireup en false en el archivo Machine.config, la página no enlazará los eventos de página a los métodos basándose en la coincidencia de nombres (por ejemplo, Page_Load). Si deshabilita AutoEventWireup, se observará una ligera mejora en el rendimiento de las páginas si se encarga el usuario mismo de la conexión de eventos en vez de hacerlo automáticamente.

      Si desea controlar los eventos de página, utilice una de estas dos estrategias. La primera estrategia es reemplazar los métodos en la clase base. Por ejemplo, puede reemplazar el método OnLoad del objeto Page para el evento de carga de página en lugar de utilizar un método Page_Load. (Asegúrese de llamar al método base para garantizar que se provocan todos los eventos.) La segunda estrategia es enlazar a los eventos mediante la palabra clave Handles en Visual Basic o la conexión automática en C#.

    • Quite los módulos no utilizados de la canalización de procesamiento de solicitudes De manera predeterminada, todas las características se mantienen activas en el nodo HttpModules del archivo Machine.config del servidor. Dependiendo de las características utilizadas en la aplicación, puede quitar los módulos que no se utilicen de la canalización de solicitudes con el fin de obtener una ligera mejora de rendimiento. Revise cada módulo y su funcionalidad y personalícelo para adaptarlo a sus necesidades. Por ejemplo, si no utiliza el estado de sesión ni el almacenamiento de resultados en caché en su aplicación, puede quitarlos de la lista HttpModules para que las solicitudes no tengan que invocar estos módulos sin realizar otros procesos significativos.

Prácticas de codificación

En las instrucciones siguientes se ofrecen sugerencias para escribir código eficaz.

  • No utilice excepciones en el código Las excepciones pueden afectar al rendimiento de manera significativa, por lo que debería evitarlas para controlar el flujo normal del programa. Si es posible detectar en el código una condición que podría provocar una excepción, hágalo en lugar de almacenar la excepción en la caché y controlar la condición. Algunos escenarios comunes que se pueden detectar en el código son comprobar si un valor es null, asignar un valor a String que se va a analizar como valor numérico o comprobar valores específicos antes de aplicar operaciones matemáticas. En el ejemplo siguiente se incluye código que causaría una excepción y código que comprueba una condición. Ambos fragmentos producen el mismo resultado.

    // This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;

    ' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If

  • Vuelva a escribir en el código administrado los componentes COM que requieran muchas llamadas .NET Framework proporciona una manera fácil de interoperar con los componentes COM tradicionales. La ventaja es que puede aprovecharse de las características de .NET al tiempo que conserva sus inversiones actuales en componentes COM. Sin embargo, en algunas circunstancias, el costo de rendimiento que supone mantener los componentes antiguos hace que compense migrarlos a código administrado. Cada situación es única, por lo que la mejor manera de decidir si se debe transformar un componente es evaluar el rendimiento del sitio Web. Se recomienda trasladar a código administrado cualquier componente COM al que se llame a menudo.

    En muchos casos, no es posible migrar componentes heredados a código administrado, en particular cuando se migran aplicaciones Web por primera vez. En estas circunstancias, uno de los mayores impedimentos con respecto al rendimiento es el cálculo de referencias de datos de un entorno no administrado a otro administrado. Por tanto, en escenarios de interoperabilidad, ejecute el máximo número de tareas en un lado o en el otro y, después, realice una única llamada en lugar de una serie de llamadas más cortas. Por ejemplo, todas las cadenas de Common Language Runtime son cadenas Unicode, por tanto, deberá convertir todas las cadenas del componente a Unicode, antes de llamar a código administrado.

    Libere los objetos COM o los recursos nativos en cuanto finalice su procesamiento. Esto permite que otras solicitudes los utilicen y reduce al mínimo los problemas de rendimiento asociados a la necesidad de que el recolector de elementos no utilizados tenga que liberarlos más tarde.

  • Evite los componentes COM de apartamentos de un solo subproceso (STA) De manera predeterminada, ASP.NET no permite que se ejecuten en una página componentes COM STA. Para ejecutarlos, debe incluir el atributo ASPCompat=true en la directiva @ Page del archivo .aspx. Este atributo cambia el grupo de subprocesos utilizado para la ejecución de páginas a un grupo de subprocesos STA, además de hacer que HttpContext y otros objetos integrados estén disponibles para el objeto COM. Evitar el uso de componentes COM STA representa una optimización del rendimiento, puesto que impide que se calculen las referencias de las llamadas de subprocesos de apartamento multiproceso (MTA, Multithreaded Apartment) a subprocesos STA.

    Cuando deba utilizar un componente COM STA, evite realizar muchas llamadas durante la ejecución e intente enviar toda la información posible durante cada llamada. Evite también crear componentes COM STA durante la construcción de la página. Por ejemplo, en el siguiente código se crearía una instancia de SampleSTAComponent durante la construcción de la página, que se ha creado a partir de un subproceso que no es el subproceso STA que ejecuta la página. Esto puede tener un impacto adverso en el rendimiento, ya que requeriría el cálculo de referencias entre los subprocesos MTA y STA para construir la página.

    <%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp as new SampleSTAComponent()
Public Sub Page_Load()
    myComp.Name = "Sample"
End Sub
</script>
<html>
<%
    Response.Write(Server.HtmlEncode(myComp.SayHello))
%>
</html>

    El mecanismo recomendado es retrasar la creación del objeto hasta que el código se ejecute en un subproceso STA, como en el ejemplo siguiente:

    <%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp
Public Sub Page_Load()
    myComp = new SampleSTAComponent()
    myComp.Name = "Sample"
End Sub
</script>
<html>
<%
    Response.Write(Server.HtmlEncode(myComp.SayHello))
%>
</html>

    La práctica más recomendable es construir los componentes COM y los recursos externos sólo cuando se precisen, o bien en el método Page_Load.

    No almacene nunca los componentes COM STA en un recurso compartido (como la memoria caché o el estado de sesión), donde subprocesos que no son el que los construyó pueden tener acceso a ellos. Aunque un subproceso STA llame a un componente COM STA, sólo el subproceso que lo ha construido puede dar servicio a la llamada, lo cual conlleva el cálculo de referencias de la llamada al subproceso creador. El cálculo de referencias puede dar lugar a reducciones importantes del rendimiento y a problemas de escalabilidad. En casos como éste, considere convertir el componente COM en un componente COM MTA o volver a escribir el componente en el código administrado.

Vea también

Conceptos

Optimizar el rendimiento en ASP.NET
Supervisar el rendimiento de una aplicación ASP.NET
Contadores de rendimiento para ASP.NET

Otros recursos

Almacenamiento en caché en ASP.NET