Consideraciones de rendimiento para las aplicaciones que utilizan servicios

Actualización: noviembre 2007

En este tema se aborda la optimización del rendimiento cuando se utilizan las características de ASP.NET, como las suscripciones, las funciones, las propiedades de perfil, los estados de sesión, la personalización de elementos Web y la exploración de sitios.

Suscripción

En esta sección se incluye información sobre cómo utilizar eficazmente la suscripción de ASP.NET.

Recopilar eficazmente listas de suscripciones

Al llamar a los métodos de la clase Membership, llame a los métodos sobrecargados que tomen PageIndex y PageSize como miembros. Estas sobrecargas se ejecutan con mayor rapidez porque se transfieren menos datos desde el servidor Web. Un ejemplo es el método GetAllUsers de la clase Membership. Si se llama al método GetAllUsers sin parámetros, se devuelven todos los usuarios suscritos. En cambio, si se llama a la sobrecarga GetAllUsers, se devuelve sólo una pagina de usuarios, por lo que se reduce la cantidad de datos procesados por la página.

Almacenar los resultados en la memoria caché al obtener el número de usuarios en línea

Se puede llamar al método GetNumberOfUsersOnline para que se muestre el número de usuarios considerados activos en el sitio Web. Este método examina cada fila de la tabla de suscripciones cada vez que se llama al método, lo que puede reducir en gran medida el rendimiento si el número de usuarios de la base de datos es elevado. Llame al método sólo cuando sea necesario y almacene el valor en la memoria caché durante un tiempo determinado si no necesita un recuento exacto.

Funciones

De manera predeterminada, el método GetRolesForUser se invoca automáticamente cada vez que se carga una página, y devuelve las funciones de un usuario. Las funciones se almacenan en un diccionario del objeto RolePrincipal. Mientras se ejecute la página Web, se comprueban las funciones mediante este diccionario. Para evitar que se obtenga acceso al proveedor cada vez que se carga una página y, por lo tanto, reducir el tiempo de procesamiento del servidor, establezca el atributo CacheRolesInCookie en el archivo Web.config de la aplicación en el valor true. De este modo, la lista de las funciones del usuario se almacena en una cookie. Cada vez que se vuelva a cargar la página, la información de las funciones se podrá leer desde la cookie en lugar de tener que llamar al proveedor.

El método GetRolesForUser, la propiedad IsInRole y el método GetRoles se pueden utilizar en código para comprobar la suscripción en una función. Si comprende cómo interactúan estos métodos, podrá escribir código para la aplicación que funcione con mayor eficacia para la tarea que necesite realizar.

El método GetRolesForUser siempre obtiene acceso al proveedor. Una llamada al método IsInRole siempre genera una llamada al método GetRolesForUser con la primera solicitud de una página cuando no está habilitado el almacenamiento en cookies. Si está habilitado, las llamadas al método IsInRole utilizarán la información de funciones almacenada en la cookie. La primera llamada al método GetRoles genera una llamada al método GetRolesForUser, independientemente de si está activado o no el almacenamiento en cookies. Sin embargo, las llamadas posteriores al método GetRoles utilizarán la información de funciones almacenada en memoria caché dentro de RolePrincipal.

Nota:
Si se almacena información confidencial en una cookie, es posible que dicha información quede expuesta a los usuarios. Para garantizar máxima seguridad, no habilite el almacenamiento en cookies.

Propiedades de perfil

Si el código obtiene acceso a las propiedades de perfil, cuando se cargue la página, el proveedor de perfiles leerá todas las propiedades de perfil del usuario actual. (En concreto, el proveedor leerá todas las propiedades asociadas a ese proveedor de perfiles.) Si cambia el valor de alguna propiedad de perfil, la nueva información se escribirá en el almacén de datos del proveedor cuando se descargue la página. ASP.NET puede determinar si los tipos intrínsecos como enteros y cadenas han cambiado, pero no puede determinar si los tipos no intrínsecos han cambiado.

El algoritmo para determinar si se guardan las propiedades de perfil es el siguiente:

Si todos los tipos de propiedades de perfil son tipos intrínsecos y no ha cambiado ninguno, no se escribe el perfil en el almacén de datos.
Si todos los tipos de propiedades de perfil son tipos intrínsecos y alguno ha cambiado, se escriben todos los valores de propiedades de perfil en el almacén de datos.
Si alguna propiedad no es un tipo intrínseco, ASP.NET no puede determinar si un valor ha cambiado. Si se obtiene acceso a la propiedad mediante código, se escribe el valor de la propiedad en el almacén de datos.

Nota:

En todos los casos, la decisión se aplica a todas las propiedades de perfil de un proveedor específico.

Nota:
En todos los casos, la decisión se aplica a todas las propiedades de perfil de un proveedor específico.

Si utiliza tipos de propiedad no intrínsecos, tardará en escribir los datos de perfil al final de cada solicitud de página. Puede resolver esta sobrecarga de las siguientes maneras:

Utilice sólo tipos intrínsecos en los perfiles.
Establezca el atributo automaticSaveEnabled del elemento de configuración <profile> en el valor Off y escriba código personalizado para detectar los cambios y guardar los valores de las propiedades cuando lo estime necesario.
Escriba código personalizado para controlar el evento ProfileAutoSaving y, en el código de evento, determine si se ha producido algún cambio en las propiedades de perfil. Si no ha cambiado ninguna propiedad, cancele la operación automática de guardar y establezca el valor de la propiedad ContinueWithProfileAutoSave del evento en false.

Estado de sesión

El rendimiento es un aspecto que debe tenerse en cuenta cuando se utiliza el modo de estado de sesión fuera de proceso (para obtener más información, vea Modos de estado de sesión). En esta sección se proporciona información sobre cómo optimizar el rendimiento del estado de sesión.

Reducir la sobrecarga de lectura y escritura del estado de sesión

De forma predeterminada, la información del estado de sesión se carga cuando se carga cada página. El atributo EnableSessionState de la directiva @ Page permite controlar la carga del estado de sesión con los siguientes valores de configuración:

True Los datos de estado de sesión se leen cada vez que se carga la página y se guardan si se han realizado cambios. ASP.NET puede determinar si los tipos intrínsecos como enteros y cadenas han cambiado. Si todos los valores de estado de sesión son tipos intrínsecos y ninguno ha cambiado, no se guarda la sesión. Si alguno de los valores no es un tipo intrínseco y se obtiene acceso a algún valor de sesión no intrínseco, se guarda toda la información del estado de sesión. Esto es debido a que ASP.NET no determina si los tipos no intrínsecos han cambiado y, para mayor seguridad, opta por guardar todos los datos.
False No se leen los datos del estado de sesión cuando se carga la página.
ReadOnly Los datos del estado de sesión se leen cada vez que se carga la página pero no se guardan nunca, incluso si se ha realizado un cambio mediante código en los valores del estado de sesión.

Evitar contenciones de bloqueo del estado de sesión

Evite utilizar elementos <IFRAME> en las páginas que requieran el estado de sesión. Si se realizan varias solicitudes a ASP.NET con el mismo identificador de estado de sesión y si las solicitudes van dirigidas todas a páginas ASP.NET donde EnableSessionState tiene el valor true, las solicitudes paralelas competirán entre sí por el bloqueo asociado al estado de sesión fuera de proceso. En el caso de los elementos <IFRAME>, esto significa que las páginas ASP.NET mostradas en varios elementos <IFRAME> de una página pueden competir entre sí por los mismos datos de sesión. El resultado es que se serializará cada solicitud en el servidor.

Personalización de elementos Web

Cuando se ejecuta una página, se carga la información de personalización de ASP.NET. Para determinar si ha cambiado la información de personalización de elementos Web, ASP.NET llama al método Equals para que compare los valores antiguos y nuevos de las propiedades marcadas con el atributo PersonalizableAttribute.

Si ha cambiado el valor de alguna propiedad de personalización, se guardan los datos de personalización. En el caso de los tipos intrínsecos como enteros, el método Equals compara directamente los valores antiguos y nuevos de las propiedades. Sin embargo, en el caso de los tipos no intrínsecos, ASP.NET compara el valor de la referencia pero no necesariamente los datos de una instancia de tipo.

Por ejemplo, en el caso de una propiedad de tipo ArrayList, el método Equals compara los valores antiguos y nuevos de la referencia ArrayList, pero no el contenido del objeto ArrayList. El método Equals devolverá true si la referencia ArrayList no ha cambiado, incluso si se ha agregado un nuevo elemento a la lista. En ese caso, no se guardan los datos de ArrayList.

Este algoritmo para los tipos no intrínsecos es eficaz, pero genera errores al no guardarse los datos. Si desea guardar los datos de un tipo no intrínseco, como un objeto ArrayList, establezca el valor de la propiedad IsDirty en true si el control se deriva de WebPart, o bien, llame al método SetPersonalizationDirty que toma un control como parámetro.

Exploración de sitios

Los mapas de sitio grandes ralentizan el rendimiento en comparación con los mapas de sitio de menor tamaño. Por ejemplo, en situaciones de prueba, si se incrementa el número de nodos de 100 a 1.000 (el número se multiplica por 10), el tiempo que tarda una página en cargarse puede incrementarse en un tercio.

La reducción de seguridad, que filtra los nodos basándose en las funciones, tiene una mayor reducción de rendimiento que el incremento del número de nodos. Por ejemplo, un mapa de sitio con 1.000 nodos tiene hasta 10 veces más sobrecarga de procesamiento que un mapa de sitio con 100 nodos.

Algunas recomendaciones para mitigar este efecto son:

Cuando está activada la reducción de seguridad, el número máximo recomendado es de 150 nodos.
Establezca el atributo Roles en cada nodo del mapa de sitio. Cuando existe este atributo Roles, ASP.NET puede omitir la autorización de dirección URL y de archivos para la dirección URL asociada a SiteMapNode mientras un usuario forme parte de una de las funciones incluidas en el atributo. Sin embargo, si un usuario no forma parte de ninguna de las funciones especificadas, ASP.NET recurrirá a las comprobaciones de autorización de archivos y dirección URL que son más lentas.
Cree una clase que herede de la clase SiteMapProvider y reemplace el método IsAccessibleToUser para que se compruebe únicamente el atributo Roles en cada nodo del mapa de sitio. De este modo, se acelera el proceso de filtrado ya que se omite la autorización de dirección URL y de archivos. No obstante, este enfoque requiere dos definiciones de seguridad paralelas en la aplicación Web. La primera es la información de autorización en el archivo Web.config (y listas de control de acceso de NTFS para la autorización de archivos si está habilitada la autenticación de Windows). La segunda es la información de funciones en el mapa de sitio. Deberá ponderar la sobrecarga para la administración de seguridad por dividir la información de seguridad respecto a la mejora de rendimiento en el procesamiento de los mapas de sitio.

Para obtener más información, vea Reducción de seguridad del mapa del sitio de ASP.NET y Autorización de ASP.NET.