Optimización de Office SharePoint Server para entornos WAN
En este artículo:
Diseño de topologías para la red WAN
Optimización del proceso de rastreo de contenido
Aceleradores de WAN y otras herramientas de terceros
Diseño de páginas para descargas más rápidas
Optimización del almacenamiento en caché para entornos WAN
En este artículo se resaltan formas específicas para optimizar la solución Microsoft Office SharePoint Server 2007 y obtener un mejor rendimiento en entornos de red de área extensa (WAN).
Diseño de topologías para la red WAN
Las funciones de servidor en una granja de servidores de Office SharePoint Server 2007 se pueden configurar de manera flexible para optimizarlas para requisitos de disponibilidad o de rendimiento específicos. En un entorno WAN, es importante comprender varias características técnicas de las funciones de servidor. Además de planear los requisitos generales de rendimiento y disponibilidad, comprender estas características le ayudará a optimizar la topología de la granja de servidores para entornos WAN.
Optimización de la topología para el rastreo de contenido
De forma predeterminada, Office SharePoint Server 2007 usa todos los servidores web para rastrear el contenido de la granja de servidores. Si la granja de servidores está configurada para usar todos los servidores web para el rastreo, el servidor de índices envía solicitudes a cada uno de los servidores web de la granja de servidores.
El rastreo de contenido en la granja impone una pesada carga en los servidores web. Esto suele causar picos en el tráfico de red y un uso intensivo de la memoria y la CPU. El rastreo de contenido en la granja de servidores podría llegar a crear más tráfico en la red que las solicitudes de usuario. Este tráfico de red puede tener consecuencias negativas en el rendimiento de todos los servidores web de la granja de servidores y, con ello, un aumento del tiempo de respuesta a las solicitudes de contenido de los sitios de SharePoint realizadas por los usuarios.
En entornos WAN, se recomienda configurar un servidor web dedicado para el rastreo de contenido, especialmente si rastrea una granja de servidores que contiene más de 500 gigabytes (GB) de contenido o si rastrea contenido en una WAN. Para asegurarse de que el rastreo de contenido no afecte a las solicitudes de usuario, quite el servidor web dedicado de la rotación de equilibrio de carga de red. Esto es especialmente importante en entornos globales, donde las horas de poca actividad de una granja de servidores regional —cuando es más probable que haya trabajos de rastreo programados— pueden coincidir con las horas punta de la granja de servidores central.
Configuración de un servidor web dedicado para el rastreo de contenido local
Para obtener el mejor rendimiento al rastrear contenido local en la granja de servidores, configure el servidor de índices como servidor web dedicado para el rastreo si el servidor de índices tiene suficiente capacidad de memoria para desempeñar ambas funciones.
En la siguiente ilustración se muestra una granja de servidores optimizada con un servidor web dedicado para la indización del contenido.
Si se usa el mismo servidor como servidor de índices y servidor web dedicado, ya no será necesario que el servidor de índices envíe solicitudes a un servidor diferente al rastrear contenido. Por tanto, se aumentará el rendimiento del rastreo y se reducirá el tráfico general de la red. Si esto no es posible, se puede usar un servidor distinto de la granja de servidores.
Se puede configurar el indizador para que use el servidor web dedicado mediante cualquiera de estas formas:
Configurar el servicio de búsqueda de Office SharePoint Server en Administración central de SharePoint
Editar directamente el archivo de hosts
Para obtener más información, vea los siguientes recursos:
Configuración de un servidor web dedicado para el rastreo de granjas de servidores remotas
Para obtener el mejor rendimiento de las granjas de servidores regionales al rastrear contenido ubicado en una granja regional, configure el servidor de índices de la granja de servidores central para que use un servidor web dedicado de la granja de servidores regional.
En la siguiente ilustración se muestran dos granjas de servidores regionales, cada una de ellas optimizada con un servidor web dedicado para la indización de contenido.
En la granja regional 1, un servidor está dedicado a la función de servidor web. Tanto la granja de servidores central como la granja regional 1 usan este servidor web dedicado para el rastreo de contenido.
La granja regional 2 se ha configurado de forma similar a la granja de servidores central y la función de servidor web se ha implementado en el servidor de índices.
Tenga en cuenta que el servidor de índices de la granja de servidores central no usa la función de servidor web en la granja de servidores central para rastrear el contenido de una granja de servidores remota. El servidor de índices se pone en contacto directamente con los servidores web de las granjas remotas.
En la ilustración anterior, si las granjas de servidores regionales rastrean contenido al mismo tiempo que la granja de servidores central, el rendimiento será mejor si se configura la granja regional 1 de las maneras siguientes:
El rendimiento del rastreo local en la granja regional 1 mejora porque el servidor web dedicado se encuentra en un servidor independiente. Por consiguiente, la granja de servidores central no afecta al rendimiento del servidor de índices.
Se reduce el tiempo de rastreo a través de la WAN. El rastreo tarda menos tiempo porque el servidor web dedicado de la granja de servidores regional responde mejor que si compartiera servidor con el servidor de índices.
El proceso de rastreo de la granja de servidores central mejora porque el servidor de índices de la granja de servidores central se comunica con un servidor web dedicado.
Si se implementa la configuración de topología que se muestra en la granja de servidores regional 2, se puede optimizar el rendimiento mediante la programación de los procesos de rastreo de ambas granjas de servidores de forma que no se superpongan.
Para usar un servidor web dedicado en una granja de servidores remota para el rastreo de contenido, debe modificar el archivo de hosts directamente. Asegúrese de editar el archivo de hosts en la granja de servidores que rastrea el contenido, no en la granja de servidores remota.
En una solución global en la que una granja de servidores central rastrea el contenido de granjas de servidores regionales, edite el archivo de hosts para incluir una entrada por cada aplicación web en cada granja de servidores regional que desee rastrear. Una entrada en el archivo de hosts incluye la dirección IP del servidor web dedicado, seguida del nombre de la aplicación web. Por ejemplo:
10.10.10.4 TeamSites
10.10.10.4 MySites
10.10.10.4 Marketing
10.10.10.4 Sales
Para obtener más información, vea Configuración de un servidor cliente web dedicado para el rastreo mediante la edición del archivo Hosts (Office SharePoint Server 2007).
Optimización para el rendimiento de las consultas
El rendimiento de las consultas para los usuarios es una consideración clave a la hora de implementar Office SharePoint Server 2007 en un entorno WAN. Cuando un usuario envía una consulta, ésta se envía a un servidor web. El servidor web se comunica con el servidor de consultas para crear una lista de resultados y, a continuación, se comunica con el equipo que ejecuta Microsoft SQL Server para ampliar la lista de resultados con texto de resumen, direcciones URL y recortes de seguridad.
Dada la comunicación entre servidores necesaria para devolver los resultados de una consulta, se puede configurar la topología para optimizar el rendimiento de las consultas. Unas pequeñas optimizaciones en la granja de servidores pueden mejorar la percepción del rendimiento general entre equipos cliente y servidores a través de la WAN.
La optimización más importante consiste en usar un servidor web dedicado para el rastreo de contenido, tal como se explica en la sección anterior. De este modo se garantiza que los servidores web estén disponibles para las solicitudes de usuario y no sobrecargados con trabajos de indización.
A continuación, hay varias opciones diferentes para implementar la función de consulta, cada una de las cuales proporciona un tipo distinto de optimización. Cada opción busca un equilibrio distinto entre la atención óptima a las solicitudes de consulta y la reducción de recorridos de red en la red local entre los servidores de la granja. En la tabla siguiente se resumen estas opciones de configuración y se indican las ventajas y desventajas de cada una de ellas.
Configuración | Ventajas y desventajas |
---|---|
Implementar la función de consulta en todos los servidores web |
Se puede hospedar la función de consulta en los servidores web para reducir las comunicaciones de ida y vuelta entre los servidores de la granja. Como resultado, se optimiza el rendimiento de las consultas. Sin embargo, dado que se hospedan dos funciones de servidor en los mismos servidores, el rendimiento general de los servidores web puede verse afectado si se hace un uso intensivo de ellos. Por consiguiente, asegúrese de implementar suficientes servidores web para procesar las solicitudes de los usuarios durante las horas punta. Aunque esta configuración optimiza el rendimiento de las consultas para los usuarios, la desventaja se aprecia en los servicios back-end de la granja. El servidor de índices propaga el catálogo de índices a cada uno de los servidores de consultas de la granja de servidores. Si la función de consulta se implementa en varios servidores web, esta operación requiere más recursos de servidor durante la propagación de los índices. |
Dedicar uno o más servidores a la función de consulta |
Si se dedica uno o más servidores para hospedar la función de consulta, se optimizan dichos servidores para que usen todos los recursos disponibles para realizar la función de forma eficaz. Normalmente, con esta configuración es posible implementar un menor número de servidores de consultas. Sin embargo, esta configuración requiere un mayor número de comunicaciones de ida y vuelta entre los servidores de la granja para atender las solicitudes de consulta de los servidores web y actualizar los índices de contenido durante la propagación de los índices. |
Implementar las funciones de consulta y de índice en el mismo servidor |
Las funciones de consulta y de índice se pueden implementar en el mismo servidor. De este modo se optimiza la comunicación en la granja de servidores porque la propagación de los índices ya no resulta necesaria. Sin embargo, esta configuración limita el número de servidores que pueden hospedar la función de consulta a un solo servidor. Esto se debe a que, cuando la función de consulta se implementa en un servidor de índices, el servidor de índices pierde la capacidad de propagar los índices de contenido a los demás servidores de la granja. |
Además de optimizar una única granja de servidores para obtener el mejor rendimiento de las consultas, hay varias opciones de optimización para escenarios con varias granjas de servidores:
En un escenario de servicios compartidos entre varias granjas de servidores en el que una granja primaria proporciona un servicio de búsqueda a una granja secundaria, implementar un servidor de consultas dedicado en la granja primaria permite a ésta controlar las consultas de búsqueda de las granjas secundarias sin afectar al rendimiento de otras opciones de usuario en la granja primaria. En un escenario de servicios compartidos entre varias granjas de servidores, el servidor web de la granja secundaria se pone en contacto directamente con el servidor de consultas y el servidor de base de datos de la granja primaria, en lugar de comunicarse a través del servidor web de la granja primaria. Tenga en cuenta que los servicios compartidos entre varias granjas de servidores en los que una granja primaria proporciona servicios a una granja secundaria no se admite a través de una WAN. Sin embargo, las organizaciones de gran tamaño pueden incluir un sitio central con una granja de servidores primaria que proporcione servicios y una granja de servidores secundaria que proporcione sitios y contenido. En este escenario, la granja de servidores primaria se puede configurar para rastrear el contenido de granjas regionales en un entorno de varias granjas distribuidas geográficamente sin afectar al rendimiento de la granja secundaria en el sitio central que proporciona sitios y contenido a los usuarios del sitio central.
En un entorno de varias granjas de servidores distribuidas geográficamente en el que una granja central rastrea el contenido de granjas regionales, se puede optimizar el rastreo del contenido y el rendimiento de las consultas mediante la configuración de los servidores de las maneras siguientes:
Implemente la función de servidor web en el servidor de índices de todas las granjas de servidores. Quite este servidor de la rotación de equilibrio de carga de red y configure el proceso de rastreo de la granja primaria para que use este servidor web dedicado para rastrear contenido.
Implemente el servidor de consultas en todos los servidores web con equilibrio de carga en cada granja de servidores.
Separación geográfica de los servidores de granjas
La comunicación entre los servidores de una granja de servidores requiere sólidas conexiones de red para atender adecuadamente a las peticiones de usuario y evitar cuellos de botella en el rendimiento. El requisito de red estándar es que todos los servidores de una granja de servidores residan en el mismo centro de datos en la misma red de área local (LAN). No se admiten servidores de granja separados por vínculos WAN.
Además de esta orientación, existen requisitos específicos que permiten a uno o varios servidores web residir en una ubicación geográfica diferente al resto de los servidores de la granja. En este escenario, los servidores web se encuentran en un centro de datos diferente, pero están conectados a la misma LAN que el equipo que ejecuta SQL Server.
Nota
Las siguientes instrucciones representan los requisitos de compatibilidad para un escenario de implementación sin documentar anteriormente.
Esta guía para este escenario es preliminar y está sujeta a cambios una vez que se realicen más pruebas. Esta guía proporciona un conjunto de directrices que se pueden usar para probar e implementar hasta que se proporcionen las instrucciones probadas oficiales. Use estas instrucciones como base para las pruebas en su propio entorno y para determinar su propio umbral de calidad y rendimiento.
Este escenario está respaldado por un soporte comercial razonable. Si las pruebas adicionales o los resultados de su propio entorno indican que este escenario presenta problemas importantes, deberá acercar los servidores web al servidor de base de datos si de esta forma se resuelven los problemas.
Este escenario de implementación debería cumplir los requisitos preliminares de compatibilidad si se cumplen las condiciones siguientes:
El vínculo de red entre un servidor web y el servidor de base de datos tiene una latencia inferior a 1 milisegundo (ms). Para conseguir esta latencia, lo ideal sería que el servidor web se encontrara a 16 kilómetros o menos del servidor de base de datos. Con las configuraciones de red más óptimas, se puede conseguir una latencia menor de 1 ms a distancias de hasta 160 kilómetros, aunque es poco frecuente. Si la distancia oscila entre 16 y 160 kilómetros, vea a sus proveedores de red y de hardware para ver si pueden proporcionar un nivel de servicio con una latencia menor que 1 ms. No se admiten servidores de granja separados por distancias superiores a los 160 kilómetros. Cuando se mida la latencia entre dos centros de datos que hospeden servidores de la misma granja de servidores, se debe usar la herramienta Ping para medir la latencia desde un servidor web que se encuentra en el centro de datos remoto hasta el servidor de base de datos del centro de datos principal. Divida el resultado de ida y vuelta entre dos.
Hay suficiente ancho de banda disponible en el vínculo para asumir el tráfico entre el servidor web y los otros servidores de la granja de servidores.
Todas las funciones de servidor que contribuyen a servicios compartidos se encuentran en el mismo centro de datos que el servidor de base de datos. Esto incluye las funciones de índice, consulta y Excel Services.
Todos los equipos de servidor de la granja de servidores están en el mismo segmento de red. No se produce conmutación en los enrutadores en la capa de datos. (Literalmente, la capa física conecta los servidores). Los enrutadores y los conmutadores aumentarán la latencia incluso aunque la conexión de red entre ellos sea muy rápida.
Si el tipo de carga que proporciona el servidor web es un subconjunto de solicitudes de exploración de usuario, es de esperar que Office SharePoint Server 2007 tolere cierta latencia entre el servidor web y el servidor de base de datos. Por otro lado, las páginas con muchos elementos web o elementos web personalizados, los comandos Stsadm y los rastreos de búsqueda no suelen responder tan bien.
Los servidores de la granja de servidores no usan varias zonas horarias. Todos los equipos de servidor de una granja de servidores deben estar sincronizados en la misma zona horaria.
Optimización del proceso de rastreo de contenido
La forma en que se programan y configuran los procesos de rastreo puede afectar al rendimiento y a la confiabilidad. Los siguientes procesos se pueden optimizar para mejorar el rastreo a través de la WAN:
Coordinar el rastreo de orígenes de contenido
Configurar la frecuencia de los rastreos y coordinar rastreos completos e incrementales
Configurar las opciones de rastreo
Coordinación del rastreo de orígenes de contenido
En entornos globales donde una granja central rastrea el contenido de granjas regionales a través de vínculos WAN, es importante planear los orígenes de contenido, dado que representan las unidades de contenido que se pueden programar y administrar.
Se agrega un origen de contenido para la búsqueda cuando se necesita:
Rastrear distintos tipos de repositorios
Usar diferentes programaciones para rastrear algunos repositorios
Limitar o aumentar la cantidad de contenido que se rastrea
Cada una de estas razones se puede tomar en cuenta para optimizar el rastreo de contenido a través de la WAN. Como mínimo, se puede crear un origen de contenido diferente para cada granja de servidores regional. Esto permite programar el rastreo de cada granja de servidores regional en función de las horas de menor actividad y la programación de mantenimiento de la granja de servidores.
Además, se pueden crear distintos orígenes de contenido para una única granja de servidores regional en función de los siguientes criterios:
Cree orígenes de contenido independientes para el contenido que desee rastrear con más frecuencia (como contenido de colaboración) o menos frecuencia (como contenido publicado).
Cree un origen de contenido independiente para el contenido que se publique de forma periódica. Por ejemplo, si sabe que el contenido de un conjunto específico de sitios sólo se actualiza los viernes, puede crear un origen de contenido independiente para sincronizar la programación de rastreo con las actualizaciones de contenido.
Cree orígenes de contenido basados en cuánto contenido se puede rastrear a través de un vínculo WAN durante las horas de poca actividad de una granja de servidores regional. Por ejemplo, si su objetivo es rastrear un repositorio de gran tamaño una vez a la semana, puede dividir el repositorio en cinco, seis o siete fragmentos de contenido que se pueden rastrear correctamente por la noche y, a continuación, escalonar los trabajos de rastreo a lo largo de cada semana.
Cree un origen de contenido independiente para el contenido que sea externo a los sitios de Office SharePoint Server 2007. En Office SharePoint Server 2007 y en Windows SharePoint Services 3.0, el registro de cambios registra los objetos modificados, incluidas las actualizaciones de las listas de control de acceso (ACL). El registro de cambios permite rastrear de forma incremental sólo el contenido modificado, lo que reduce considerablemente el tiempo necesario para volver a rastrear un origen de contenido. El contenido almacenado en orígenes externos no se puede rastrear de forma incremental. Por lo tanto, el proceso de rastreo de dichos orígenes de contenido debe administrarse por separado. Para obtener más información, vea el artículo referente al registro de cambios (https://go.microsoft.com/fwlink/?linkid=106007&clcid=0xC0A).
Para obtener más información acerca de la planeación de rastreos y de los orígenes de contenido, vea Planeación del rastreo de contenido (Office SharePoint Server).
Configuración de la frecuencia de los rastreos y coordinación de rastreos completos e incrementales
Tal y como se explicó en la sección anterior, una de las principales razones por las que se crean orígenes de contenido independientes es para tener la capacidad de rastrear contenido en diferentes programaciones. Esto es especialmente importante en entornos donde el contenido se rastrea a través de vínculos WAN con latencias altas. Al programar trabajos de rastreo para granjas de servidores regionales, tenga en cuenta los siguientes factores:
Tiempos de inactividad programados y períodos de máximo uso de la granja de servidores regional.
Frecuencia con la que el contenido se modifica o actualiza.
Ancho de banda disponible y latencia del vínculo WAN. Asegúrese de tener en cuenta los demás procesos que usan el vínculo WAN.
Para cada origen de contenido en Office SharePoint Server 2007 y en Windows SharePoint Services 3.0, puede especificar un momento para realizar rastreos totales y otro momento distinto para realizar rastreos incrementales. Tenga en cuenta que es necesario realizar primero un rastreo completo de un origen de contenido dado para poder realizar uno incremental. Si elige realizar un rastreo incremental de contenido que todavía no se ha rastreado, el sistema realizará un rastreo completo.
Cuando planee las programaciones de rastreo para un entorno WAN, tenga presentes los siguientes procedimientos recomendados:
Escalone las programaciones de rastreo de forma que el uso de los vínculos WAN se distribuya a lo largo del tiempo y éstos no se saturen.
Programe rastreos completos sólo cuando sea necesario. Se recomienda que los rastreos completos sean menos frecuentes que los incrementales.
Programe rastreos incrementales de cada origen de contenido durante períodos en los que los servidores que hospedan el contenido estén disponibles y cuando la demanda de recursos del servidor sea baja.
Algunos cambios administrativos de Office SharePoint Server 2007 y Windows SharePoint Services 3.0, como aplicar un Service Pack o restaurar una base de datos, desencadenan de forma automática un rastreo completo durante el siguiente rastreo programado con regularidad. Programe los cambios administrativos que requieran un rastreo completo para que tengan lugar poco antes de la programación planeada de rastreos completos. Por ejemplo, es recomendable que intente programar la creación de la regla de rastreo antes del siguiente rastreo completo programado de forma que no sea necesario realizar otro rastreo completo. Para obtener más información acerca de los cambios administrativos que requieren un rastreo completo, vea las razones para realizar un rastreo completo en Planeación del rastreo de contenido (Office SharePoint Server).
Importante
Después de aplicar la Actualización de infraestructura para servidores de Microsoft Office, las futuras actualizaciones y la restauración de bases de datos no desencadenarán de forma automática un rastreo completo. Por lo tanto, cuando aplique futuras actualizaciones o restaure una base de datos, la búsqueda continúa el rastreo según la programación regular definida por las reglas de rastreo. Para obtener más información, vea Planeación del rastreo de contenido (Office SharePoint Server).
Además de estos procedimientos recomendados que se aplican al rastreo de contenido en sitios regionales individuales, asegúrese de que la programación general de rastreos de una granja de servidores central no sobrecargue el servidor de índices. Realice los rastreos simultáneos en función de la capacidad del servidor de índices para rastrearlos. El rendimiento del servidor de índices y de los servidores que hospedan el contenido determina hasta qué punto se pueden superponer los rastreos. Con el tiempo, según se vaya familiarizando con lo que suelen durar los rastreos para cada origen de contenido, estará preparado para desarrollar una estrategia de programación.
Para obtener más información acerca de la planeación de rastreos y de los orígenes de contenido, vea Planeación del rastreo de contenido (Office SharePoint Server).
Configuración de las opciones de rastreo
Puede optimizar varias opciones de rastreo específicas de entornos WAN para aumentar la confiabilidad de los trabajos de rastreo. Las siguientes configuraciones están disponibles:
Configuración del tiempo de espera de búsqueda
Reglas de impacto del rastreador
Configuración del tiempo de espera de búsqueda
Los administradores de la granja de servidores pueden especificar la cantidad de tiempo que desean que espere el servidor al conectar con otros servicios y cuánto tiempo esperará a que se confirme una solicitud de contenido. Si agrega orígenes de contenido que se rastrean a través de vínculos WAN, aumente la configuración del tiempo de espera como medida proactiva según la latencia total del vínculo. Puede ajustar la configuración del tiempo de espera en cualquier momento en función del rendimiento real del rastreo de contenido a través de un vínculo WAN.
Realice el siguiente procedimiento para especificar la configuración del tiempo de espera para el servicio de búsqueda de Office SharePoint Server.
Especificación de la configuración del tiempo de espera
En la sección Buscar de la ficha Administración de aplicaciones de Administración central, haga clic en Administrar el servicio de búsqueda.
En la página Administrar el servicio de búsqueda, en la sección Configuración de búsqueda en granjas de servidores, haga clic en Configuración de búsqueda en granjas de servidores.
En la página Administrar la configuración de búsquedas en granjas de servidores, en la sección Configuración del tiempo de espera, haga lo siguiente:
En el cuadro Tiempo de conexión (en segundos), escriba el número de segundos que desea que espere el servidor mientras se conecta con otros servicios.
En el cuadro Tiempo de confirmación de solicitud (en segundos), escriba el número de segundos que desea que espere el servidor hasta que otro servicio confirme una solicitud de conexión a ese servicio.
Haga clic en Aceptar.
Reglas de impacto del rastreador
Las reglas de impacto del rastreador proporcionan un modo de controlar el número de documentos que se solicitan y rastrean en un momento dado. Las reglas de impacto del rastreador permiten a los administradores controlar el impacto que tienen los trabajos de rastreo en los vínculos WAN.
Para cada regla de impacto del rastreador, puede especificar una sola dirección URL o usar caracteres comodín en la dirección URL para incluir un bloque de direcciones URL al cual se aplicará la regla. A continuación, puede especificar el número de solicitudes simultáneas de páginas que se realizarán para la dirección URL especificada, u optar por solicitar un solo documento cada vez y esperar el intervalo en segundos que elija entre las solicitudes.
Durante la implementación inicial, establezca las reglas de impacto del rastreador para usar los vínculos WAN de la forma más eficaz posible mientras se sigue rastreando con la adecuada frecuencia el suficiente contenido para garantizar que el contenido rastreado esté actualizado. Más adelante, durante la fase de operaciones, puede ajustar las reglas de impacto del rastreador basándose en sus experiencias y en los datos de los registros de rastreo.
Realice el siguiente procedimiento para agregar una regla de impacto del rastreador.
Adición de una regla de impacto del rastreador
En la sección Buscar de la ficha Administración de aplicaciones de Administración central, haga clic en Administrar el servicio de búsqueda.
En la página Administrar el servicio de búsqueda, en la sección Configuración de búsqueda en granjas de servidores, haga clic en Reglas de impacto del rastreador.
En la página Reglas de impacto del rastreador, haga clic en Agregar regla.
En la sección Sitio de la página Agregar regla de impacto del rastreador, escriba el nombre del sitio que estará asociado a esta regla de impacto del rastreador en el cuadro Sitio.
Nota
Al escribir la dirección URL, debe excluir el protocolo. No incluya, por ejemplo, http:// o file://.
En la sección Frecuencia de solicitudes, elija una de las siguientes opciones:
Solicitar simultáneamente el número de documentos especificado como máximo y no esperar entre solicitudes. Si elige esta opción, use la lista Solicitudes simultáneas para especificar el número de documentos que desea que el rastreador solicite al mismo tiempo cuando rastree esta dirección URL. Puede especificar el número máximo de solicitudes que puede realizar el servicio Office SharePoint Services Search simultáneamente al rastrear esta dirección URL.
Solicitar documentos de uno en uno y esperar el tiempo especificado entre solicitudes. Puede especificar el retraso (en segundos) que desea que haya entre las solicitudes cuando se rastree esta dirección URL. Cuando se selecciona esta opción, el servicio de búsqueda de Office SharePoint Server realiza una solicitud por sitio cada vez y después espera el tiempo especificado antes de realizar la siguiente solicitud. En el cuadro Tiempo de espera (en segundos), escriba los segundos que deben transcurrir entre las solicitudes. El tiempo mínimo de espera entre solicitudes es de un segundo y el máximo es de 1.000 segundos.
Haga clic en Aceptar.
Para obtener más información acerca de las reglas de impacto del rastreador, vea los siguientes artículos:
Administración del impacto del rastreador (Office SharePoint Server 2007).
"Reglas de impacto del rastreador" en Rendimiento estimado y requisitos de capacidad para entornos de búsqueda.
Aceleradores de WAN y otras herramientas de terceros
En esta sección se describen las opciones para optimizar entornos WAN con soluciones de terceros en las siguientes categorías:
Aceleradores de WAN
Dispositivos de descarga y de memoria caché
Soluciones de cliente
Replicación de datos, sincronización con varios maestros y administración de la configuración
Facilidad de administración de varias granjas de servidores y creación de informes
Replicación de nivel de bytes o basada en hardware
Dado que cada entorno es diferente, no se recomiendan soluciones de asociados específicas. Además, las soluciones de asociados abordan las oportunidades de diferentes maneras. Por consiguiente, cada solución tiene distintos puntos fuertes. Es importante evaluar cada solución teniendo en cuenta las necesidades específicas de su entorno y los puntos fuertes relativos de la solución del asociado.
Hay muchos asociados que ofrecen soluciones para mejorar u optimizar soluciones de Office SharePoint Server 2007. Para obtener una lista actualizada de asociados, vea Soluciones de Office System (https://go.microsoft.com/fwlink/?linkid=108591&clcid=0xC0A).
Aceleradores de WAN
Las soluciones de aceleración de WAN se usan desde hace mucho tiempo. Durante décadas han existido algoritmos con rutas de acceso más cortas y herramientas de compresión de paquetes. En los últimos años, las innovaciones más importantes se centran en la optimización de la pila TCP/IP y el bloque de mensaje de servidor (SMB).
La mayoría de los aceleradores de WAN trabajan en pareja, con un dispositivo instalado en el centro de datos junto a los servidores que ejecutan Productos y Tecnologías de SharePoint y otro dispositivo en la sucursal. Los dos dispositivos optimizan el tráfico de WAN mediante almacenamiento en caché, compresión, diferenciación y métodos propietarios para optimizar los paquetes que se envían entre los dos dispositivos. El enfoque es similar tanto si ambos dispositivos están incorporados o sencillamente son equipos en red con actualizaciones para la memoria caché. Las distintas soluciones de asociados se centran en optimizar distintos niveles dentro de la pila de red.
Dos criterios importantes que hay que considerar al elegir un acelerador de red son:
Los requisitos de seguridad de su organización. Determinados requisitos como IPsec o HTTPS influirán en las opciones.
Las aplicaciones usadas en la organización. Si desea un dispositivo que también proporcione optimización para Microsoft Exchange Server y tráfico entre recursos compartidos, esto también influirá en las opciones.
Entre algunas soluciones de ejemplo se encuentran Cisco, Citrix, Packeteer, Riverbed y F5.
Dispositivos de descarga y de memoria caché
Si bien las técnicas de almacenamiento en caché en SharePoint pueden reducir el tráfico de back-end innecesario, los asociados que proporcionan dispositivos de descarga y de memoria caché pueden ayudar a salvar el vacío existente, incluidas las conexiones WAN, entre el cliente y los servidores.
Si su sitio de SharePoint se hospeda en Internet y su objetivo es optimizar el tráfico de red y reducir el número de solicitudes que reciben sus servidores, entonces los dispositivos de descarga y de memoria caché pueden ser de utilidad. Hay una gran variedad de asociados con soluciones para optimizar el proceso de hospedar contenido expuesto a Internet. Entre las estrategias usadas en este espacio se incluyen el almacenamiento en caché y las técnicas propietarias relacionadas, la compresión de descarga con distintos algoritmos, las preparaciones y las capturas previas, y varias técnicas de carro de compra. Algunos asociados destacan a la hora de ofrecer contenido de forma segura y eficaz a tipos de clientes específicos, como quioscos públicos, equipos en cibercafés en cualquier parte del mundo y otros dispositivos ligeros que no están bien conectados.
En el área de Internet también hay asociados que proporcionan almacenamiento en caché global y técnicas de enrutamiento de optimización de redes para reducir el número de paquetes perdidos. Por ejemplo, algunas soluciones optimizan el tráfico de red de modo que sólo las diferencias en las solicitudes de cliente se envían al servidor. Estos tipos de soluciones dan como resultado menos tráfico de WAN y devoluciones de páginas más rápidas, ya que reducen el número de comunicaciones de ida y vuelta entre el cliente y el servidor o entre otros dispositivos intermedios.
De forma similar a Microsoft ISA, algunas soluciones proporcionan autenticación de descarga o delegada como puerta de enlace para tener acceso a la información. Estas soluciones agregan una capa adicional de seguridad. Para cumplir varios requisitos, busque productos o soluciones que proporcionen un firewall y equilibrio de carga, además de inteligencia para la descarga y el almacenamiento en caché. Espere una consolidación todavía mayor de este tipo de características en el futuro.
Las soluciones de ejemplo incluyen Cisco, F5, Inktomi, Microsoft ISA Server y Microsoft Internet Application Gateway.
Soluciones de cliente
Algunos asociados se centran en optimizar la experiencia del cliente, en lugar de la infraestructura de servidor y de red. Algunas técnicas, como la captura previa, la sincronización en segundo plano, la compresión, los bloqueadores de anuncios y los filtros de imágenes pueden aumentar considerablemente el rendimiento de recuperar contenido de Internet. Esto es especialmente cierto si el objetivo principal es texto y puede pasar sin imágenes.
Hay varias aplicaciones cliente que permiten a los usuarios sincronizar con sitios de SharePoint automáticamente. Una vez que el cliente sincroniza con un sitio por primera vez, la aplicación cliente automáticamente almacena en caché el contenido del sitio en el equipo cliente en segundo plano o cuando el cliente está en línea. Por ejemplo, cuando un usuario hace clic en un documento, el documento ya está disponible localmente y al usuario no le afectan los vínculos WAN. De forma similar, cuando un usuario agrega o actualiza un documento, la aplicación cliente se encarga de sincronizar los cambios con el sitio en línea. Normalmente, estas aplicaciones administran los conflictos que surgen y permiten que los usuarios decidan cómo resolver los conflictos.
Algunos clientes controlan esta experiencia mejor que otros. Algunos únicamente proporcionan compatibilidad con archivos. Algunas aplicaciones proporcionan compatibilidad tanto con listas como con archivos. Es probable que no encuentre Wikis sin conexión, pero puede encontrar lectores RSS para usar la mayoría de listas de forma local o sin conexión. Office Outlook 2007 es un ejemplo de cliente que permite usar listas y blogs de SharePoint sin conexión mediante el uso de RSS con un lector RSS, además de sincronizar con bibliotecas de documentos. Office Groove 2007 también proporciona una buena experiencia sin conexión y agrega las capacidades de compresión de archivos y colaboración de igual a igual a través de una WAN. Para obtener más información acerca de las soluciones de cliente de Microsoft, vea Ampliación de soluciones globales de Office SharePoint Server con software de Office Outlook 2007 y Office Groove.
Los asociados en este espacio se han centrado en optimizar la experiencia del usuario allí donde los vínculos WAN afectan al rendimiento o donde los clientes suelen estar sin conexión. El almacenamiento en caché (copias locales), la compresión y el traslado de la sincronización al segundo plano pueden producir la sensación de que se encuentra en la LAN con el servidor. Si decide ofrecer a los usuarios aplicaciones cliente, asegúrese de proporcionar un aprendizaje adecuado, de modo que los usuarios puedan trabajar de la forma más eficaz posible.
Asociados: Colligo. Microsoft: Microsoft Office Outlook 2007, Office Groove 2007
Replicación de datos, sincronización con varios maestros y administración de la configuración
A menudo, la replicación es necesaria en los planes de implementación, tanto si se debe a vínculos WAN lentos entre dos oficinas o a requisitos de recuperación de desastres con un requisito de varios maestros. SQL Server 2005 proporciona trasvase de registros y creación de reflejo de bases de datos para la recuperación de desastres o la conmutación por error de sitios. Sin embargo, cuando se necesiten dos granjas de servidores independientes que proporcionen acceso de lectura y escritura, se puede recurrir a las soluciones que ofrecen los asociados.
Algunas soluciones de asociados incluyen una memoria caché de servidor similar a un acelerador de WAN. Las soluciones siguen proporcionando contenido de la memoria caché en un sitio remoto si se produce un error en un vínculo WAN. Otros asociados destacan en la sincronización de datos cuando los sitios están conectados después de períodos prolongados sin conexión. Por ejemplo, un barco que llega a un muelle después de estar en alta mar puede sincronizar con un sitio central.
Algunos asociados amplían la interfaz de Productos y Tecnologías de SharePoint para configurar la replicación de pares de aplicaciones web, colecciones de sitios o listas.
Nota
Las características de publicación de Office SharePoint Server 2007 aún no han sido probadas por el equipo del producto en entornos WAN. Las características de publicación podrían aportar valor al publicar contenido de una granja central en entornos de solo lectura. Sin embargo, sin los resultados de las pruebas, no se pueden proporcionar directrices específicas para este escenario.
Entre las soluciones de asociados se encuentran Syntergy, WinApp Technologies, Casahl e Infonic.
Facilidad de administración de varias granjas de servidores y creación de informes
En las implementaciones globales que incluyen varias granjas de servidores, administrar la configuración de todas las granjas y sitios puede ser un desafío. Hay varios asociados que ofrecen herramientas diseñadas para simplificar la administración de las opciones de configuración, la administración de permisos, los derechos de usuario eficaces y los elementos de contenido, como páginas maestras y tipos de contenido. Si decide implementar varias granjas de servidores en su entorno, tenga en cuenta las herramientas de asociados que pueden ayudarle a administrar varias granjas de servidores y grandes volúmenes de sitios.
Algunos asociados se centran en ayudarle a configurar opciones de configuración para varias granjas de servidores y entornos. SharePoint Cross Site Configurator (en inglés) (https://go.microsoft.com/fwlink/?linkid=108592&clcid=0xC0A) (en inglés) es un ejemplo de herramienta diseñada por Microsoft para configurar la auditoría, la expiración, las páginas maestras y los tipos de contenido de forma coherente entre las aplicaciones web.
Entre las soluciones de asociados se encuentran Quest Software, echoTechnologies, IDevFactory, AvePoint, CorasWorks, Barracuda Tools, CommVault y Symantec.
Replicación de nivel de bytes o basada en hardware
Los asociados que proporcionan replicación basada en hardware o de nivel de bytes facilitan la conmutación por error y la sincronización de entornos entre centros de datos. Si implementa un disco compartido como una red de área de almacenamiento (SAN), el disco compartido puede convertirse en un punto de errores. Los proveedores de hardware usan distintos métodos para proporcionar canales, fibra y discos redundantes, así como varias configuraciones de matriz. Las distintas soluciones proporcionan diferentes niveles de tolerancia a errores.
Si desea eliminar el hardware como origen potencial de errores, evalúe Microsoft Cluster Services (MSCS). MSCS proporciona tolerancia a errores basada en hardware. Las soluciones de conmutación por error basadas en software, como el trasvase de registros y la creación de reflejo de SQL, proporcionan tolerancia a errores de hardware, pero la conmutación por error no es automática cuando se usa con Productos y Tecnologías de SharePoint.
En algunos casos, la implementación de una solución que proporciona replicación en un nivel inferior de la pila puede satisfacer necesidades empresariales específicas. La replicación de nivel de bytes, que crea un clon o espejo del entorno principal, también puede crear un entorno secundario al que conmutar por error. La replicación de nivel de bytes continua puede proporcionar un medio para la conmutación por error automática o manual.
Una precaución importante al evaluar estos tipos de soluciones de replicación es comprender que los nombres de servidor, los nombres de aplicaciones web y las cuentas están codificados en la base de datos de configuración. Esto significa que cualquier servicio que se replique en un servidor distinto con un nombre diferente no funcionará. Si el nombre del servidor sigue siendo el mismo tanto en el entorno replicado como en el entorno principal, estos tipos de soluciones pueden funcionar. Independientemente de la solución, si una herramienta proporciona replicación sin el conocimiento de la aplicación, se debe probar la herramienta para garantizar su funcionamiento en un entorno de conmutación por error.
Entre las soluciones de asociados se incluyen Neverfail y Double-take.
Las soluciones integradas en el hardware, como la replicación basada en SAN, incluyen HP, EMC Centera e Hitachi Data Systems.
Diseño de páginas para descargas más rápidas
En un entorno con capacidad de red limitada, simplifique las páginas y hágalas tan pequeñas y receptivas como sea posible. Existen diferentes técnicas para lograrlo, la mayoría de las cuales no son específicas de Productos y Tecnologías de SharePoint. Los métodos generales que se pueden usar en cualquier sitio web no se tratarán con detalle en esta sección. Por el contrario, en esta sección nos centraremos en comprender las características incluidas en Productos y Tecnologías de SharePoint, qué se incluye en la página y formas para acelerar la primera visita a un sitio de SharePoint.
Elementos de página
Una página de un sitio de SharePoint consiste en varios elementos únicos, como se muestra en la siguiente ilustración.
Cuando se representa la página, se combina la página maestra, la página de diseño y el contenido de la página. El contenido de la página incluye los valores de cada uno de los campos de la página, pero también otros elementos como el tema, las hojas de estilo, las imágenes y la navegación. En la tabla siguiente se muestra un ejemplo de los archivos y secuencias presentes en una sola página de un sitio de SharePoint. Este ejemplo es una captura de todas las solicitudes HTTP que se realizaron durante la visita inicial a la página principal predeterminada de un sitio del portal de colaboración.
Dirección URL | Tamaño (bytes) |
---|---|
http://myServer/_layouts/images/topnavhover.gif |
96 |
http://myServer/Pages/Default.aspx |
1656 |
http://myServer/Pages/Default.aspx |
1539 |
http://myServer/Pages/Default.aspx |
66084 |
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D |
1448 |
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D |
642 |
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D |
1317 |
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D |
13596 |
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D |
15732 |
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D |
54367 |
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D |
954 |
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D |
20508 |
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D |
5092 |
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D |
2735 |
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034 |
5383 |
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034 |
8258 |
http://myServer/_layouts/images/blank.gif |
43 |
http://myServer/_layouts/images/helpicon.gif |
1025 |
http://myServer/_layouts/images/Menu1.gif |
68 |
http://myServer/_layouts/images/titlegraphic.gif |
1299 |
http://myServer/_layouts/images/gosearch.gif |
19933 |
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034 |
224 |
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034 |
218 |
http://myServer/_layouts/images/whitearrow.gif |
68 |
http://myServer/_layouts/images/recycbin.gif |
1004 |
http://myServer/PublishingImages/newsarticleimage.jpg |
10710 |
http://myServer/_layouts/images/icongo01.gif |
1171 |
http://myServer/_layouts/images/menudark.gif |
68 |
http://myServer/_layouts/images/topnavhover.gif |
96 |
Tenga en cuenta lo siguiente:
Se necesitó un total de 29 solicitudes para descargar la página.
El tamaño de página total fue de 235 kilobytes (KB).
Esto representa la carga de la página inicial; casi todos los elementos de la solicitud tienen una directiva de almacenamiento en caché que indica al explorador que no vuelva a cargarlos de nuevo en un año. La carga de la segunda página y siguientes sólo produce tres solicitudes. De ellas, dos forman parte de la negociación NTLM que tiene lugar, por lo que realmente sólo se descarga un elemento: el código HTML para la página.
Se usó el nivel 0 de compresión IIS predeterminado, que es la menor cantidad de compresión posible. Una compresión mayor daría como resultado tamaños de descarga aún más pequeños.
De los distintos tipos de archivo cargados, había:
4 solicitudes de recursos .axd
4 solicitudes de recursos .css
12 solicitudes de recursos de imagen
6 solicitudes de recursos .js (varias de las cuales estaban duplicadas)
3 solicitudes de recursos de página para default.aspx (dos de las cuales eran parte de la negociación NTLM)
La mayoría de estos tipos de archivo son bastante obvios, con la posible excepción del tipo de recurso .axd. Un recurso .axd forma parte de una nueva característica en ASP.NET versión 2.0. Un programador puede agregar un recurso, como un archivo de script o una hoja de estilos, a un control. En el control, el programador usa la clase ClientScript para incluir un método llamado GetWebResourceUrl. Cuando el control se representa en tiempo de ejecución, genera dinámicamente una dirección URL para el recurso. El propio recurso se compila en el ensamblado del control, por lo que esta metodología proporciona una forma de transmitir ese recurso fuera del ensamblado y hasta el cliente, como si se tratara de un archivo independiente ubicado en el servidor web.
Conocer las solicitudes de recursos usadas por la página le ayudará a comprender dónde y cómo se pueden aplicar las optimizaciones. Este tipo de información se puede medir con una gran variedad de herramientas y técnicas. Para este artículo se usó una herramienta de software gratuito llamada Fiddler (en inglés). Fiddler se puede ejecutar en una estación de trabajo cliente y realiza el seguimiento de todas las solicitudes HTTP que se efectúan para una página. A continuación, presenta los resultados en una cuadrícula, tal como se muestra en la siguiente ilustración.
Realice pruebas del sitio con Fiddler a medida que vaya cambiándolo para optimizarlo. Para obtener la idea más precisa de qué elementos se solicitan, qué elementos se almacenan en la memoria caché y el tamaño de cada elemento:
Elimine todos los archivos temporales de su explorador.
Inicie Fiddler.
Solicite la página.
Nota
Asegúrese de que hace clic en un vínculo para solicitar la página. Si sólo hace clic en el botón Actualizar, el sistema vuelve a solicitar automáticamente los elementos y no refleja de forma precisa los cambios de optimización que se han realizado.
Optimización de las descargas de páginas
Una vez que conoce la composición de la página, puede usar distintos métodos para optimizar la experiencia de descarga de esa página. En general, el objetivo es minimizar el número de recorridos de ida y vuelta entre los equipos cliente y los equipos servidor, y reducir la cantidad de datos que circulan a través de la red. Entre la información de este artículo se incluyen recomendaciones que se pueden aplicar de forma general a una gran variedad de implementaciones de Productos y Tecnologías de SharePoint.
Es necesario recordar una distinción importante al revisar estas recomendaciones y cualquier otra optimización personalizada que pueda desarrollar. Las técnicas de optimización de páginas se pueden clasificar en dos categorías: la primera solicitud de página y las solicitudes de página siguientes. Las optimizaciones para la primera solicitud de página son aquellas que se implementan la primera vez que se solicita la página, pero que no afectan necesariamente a las solicitudes de página siguientes. Las optimizaciones de las solicitudes de página siguientes son aquellas que pueden mejorar la experiencia del usuario tanto si es la primera vez que el usuario solicita la página como si es la quincuagésima. La clave es que necesita establecer un equilibrio entre la pérdida de funcionalidad y las ganancias obtenidas. Si las ganancias sólo se experimentan la primera vez que un usuario visita un sitio, puede que la optimización no compense la pérdida de funcionalidad.
Caché BLOB
La memoria caché de objetos binarios grandes (BLOB) se trata con más detalle más adelante en este artículo. En resumen, se puede usar para aplicar directivas de caché a elementos en una página almacenada en Productos y Tecnologías de SharePoint. Si esas directivas de caché se incluyen, el explorador no intentará descargar de nuevo esos elementos hasta que expire el elemento almacenado en caché. Como se ilustró en el anterior ejemplo de página principal, casi todos los elementos incluidos en la página principal predeterminada para la plantilla del sitio Portal de colaboración tenían una directiva de almacenamiento en caché asociada a ellos. Por esa razón no recibían solicitudes en las visitas siguientes realizadas a la página. Para obtener más información acerca de cómo configurar la memoria caché BLOB, vea Optimización del almacenamiento en caché para entornos WAN más adelante en este artículo.
Compresión IIS
La compresión IIS también se aborda con más detalle en la sección Optimización del almacenamiento en caché para entornos WAN de este documento. Sin embargo, como se ha indicado anteriormente, la configuración predeterminada usa un nivel de compresión de 0. Debe probar con los distintos niveles de compresión hasta que encuentre uno que optimice la compresión al tiempo que se minimiza el impacto en las CPU de los servidores web. En prácticamente todos los casos, puede usar un nivel de compresión mayor que 0. Sin embargo, es importante que recuerde que el nivel de compresión sólo se aplica a archivos dinámicos como, por ejemplo, archivos .axd y .aspx.
Hardware de 64 bits
Las opciones de hardware de la granja de servidores también pueden afectar a la latencia de las solicitudes. Los sistemas de 32 bits tienen un límite de memoria de 2 gigabytes (GB) de RAM por aplicación. Aunque se puede ampliar hasta los 3 GB de RAM, el uso del conmutador /3GB no es compatible con Productos y Tecnologías de SharePoint. Cuando se producen situaciones de poca memoria, la latencia de las solicitudes se puede ver afectada negativamente de las maneras siguientes:
Si la cantidad de memoria queda restringida, puede ocasionar que el grupo de aplicaciones de SharePoint se recicle. A su vez, esto obliga al dominio de la aplicación ASP.NET a reciclarse, lo que puede causar un gran retraso en las respuestas a las solicitudes de usuario.
Los errores de memoria insuficiente pueden provocar que la memoria caché BLOB deje de suministrar contenido.
Mediante el uso de hardware de 64 bits, se asegura el poder asignar y usar suficiente memoria RAM para evitar estos errores.
Configuración del hospedaje multiproceso en una única máquina
La configuración del hospedaje multiproceso en una única máquina puede provocar involuntariamente que la memoria caché BLOB funcione de manera desigual. Dado que sólo un proceso puede adquirir el bloqueo necesario para administrar la memoria caché, el uso correcto de ésta dependerá del subproceso que atienda la solicitud. Si un hospedaje multiproceso en una única máquina que no tiene bloqueo de memoria caché BLOB atiende una solicitud, el contenido que se envía en respuesta no tendrá las directivas de almacenamiento en caché asociadas a él. Esto aumenta el número de solicitudes y la cantidad de datos enviados a través de la red. Por lo tanto, si va usar la memoria caché BLOB, no debería usar el hospedaje multiproceso en una única máquina.
Minimización de los elementos protegidos en la página
Cuando un usuario se autentica en Productos y Tecnologías de SharePoint, ocurren dos cosas: en primer lugar, el sistema valida las credenciales para determinar quién es el usuario; en segundo lugar, el proveedor de funciones enumera la lista de grupos de SharePoint a los que pertenece el usuario. Cada vez que se solicita una página, se vuelve a llamar al proveedor de funciones para que enumere todos los grupos a los que pertenece el usuario.
Sin embargo, esta llamada para la pertenencia a grupos puede producirse varias veces en una misma página. Por ejemplo, la página de la plantilla del sitio Portal de colaboración predeterminada requiere dos llamadas al proveedor de funciones cuando se visita la página principal: una para la propia página y otra para la imagen en la página. Cada imagen que se almacena en una biblioteca de SharePoint y está en la página requerirá una llamada adicional al proveedor de funciones para comprobar los permisos, incluso si todas las imágenes se almacenan en la misma biblioteca de imágenes. Dicha comprobación ocurre tanto si las imágenes se agregan como campos en la página —es decir, como parte del contenido de la página— como si se agregan a la página maestra del sitio.
Un sitio desarrollado para un ancho de banda limitado o un entorno de alta latencia se debe diseñar para usar el menor número de imágenes en la página. Muchos sitios usan varias imágenes como parte de su página maestra para crear distintos efectos visuales. Dado que la latencia aumentará cuanto mayor sea el número de comprobaciones de seguridad, los sitios para estos entornos se deben diseñar para que usen el menor número posible de imágenes.
Minimización del número y el tamaño de las imágenes
Tal como se describe en la sección anterior, se debe minimizar el número de imágenes en el sitio. Para ayudarle en esa tarea, puede incrustar varias imágenes en un único archivo y, a continuación, hacer referencia a cada imagen en la página de forma individual. No sólo disminuirá el tamaño de descarga de los archivos, sino que el menor número de archivos dará como resultado menos tráfico de red. Es más complicado crear páginas mediante esta técnica, pero en situaciones donde es importante cada recorrido de ida y vuelta y cada tamaño de archivo, puede convertirse en una valiosa forma de ayudarle a mejorar el rendimiento. En la siguiente ilustración se muestra un ejemplo de un único archivo de imagen que contiene varias imágenes.
La siguiente ilustración muestra cómo esta imagen se cambia posteriormente para mostrarse como imágenes individuales en una tabla.
La manipulación de las imágenes se realizó completamente mediante clases de hojas de estilos. Se usaron dos clases principales en los elementos div
e img
de cada celda de la tabla. Esas clases son las siguientes:
.cluster {
height:50px;
position:relative;
width:50px;
}
.cluster img {
position:absolute;
}
Cada imagen tiene una clase asociada basada en el identificador de la imagen. Ese estilo recorta la imagen y define un desplazamiento de la imagen inicial en el clúster. Estas clases son las siguientes:
#person {
border:none;
clip:rect(0, 49, 49, 0);
}
#keys {
clip:rect(0, 99, 49, 50);
left:-50px;
}
#people {
clip: rect(0, 149, 49, 100);
left:-100px;
}
#lock {
clip:rect(0, 199, 49, 150);
left:-150px;
}
#phone {
clip:rect(0,249, 49, 200);
left:-200px;
}
#question {
clip:rect(0, 299, 49, 250);
left:-250px;
}
El código HTML de la tabla incluye las etiquetas div
y img
con los valores de identificador y los nombres de clase adecuados, de la manera siguiente:
<table border="1">
<tr>
<td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>
<td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>
<td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>
</tr>
<tr>
<td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>
<td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>
<td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>
</tr>
</table>
Varios productos y propiedades web de Microsoft usan ahora esta técnica, incluidos Microsoft Passport Network y Microsoft Office Outlook Web Access (OWA). El equipo de MSN ha realizado algunas pruebas de rendimiento para analizar el impacto de los cambios y ha descubierto una mejora en el tiempo de carga para la primera página de entre el 50% y el 75%.
Hay un punto importante que se debe tener en cuenta si se van a crear las páginas en Microsoft Office SharePoint Designer 2007. Cuando se crea una nueva página en Office SharePoint Designer 2007, se agrega automáticamente el siguiente marcado de esquema XHTML a la página:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
It then adds this namespace to the HTML element:
<html xmlns="http://www.w3.org/1999/xhtml">
Si usa este esquema, las imágenes no se alinearán correctamente. Debe quitar el atributo xmlns
de la etiqueta HTML para que las imágenes aparezcan como se espera.
Demora en la descarga de core.js
El principal archivo de script de cliente incluido con Office SharePoint Server 2007 se denomina core.js. Es el archivo de script de mayor tamaño, de aproximadamente 257 KB sin comprimir y aproximadamente 54 KB comprimido. En ciertas situaciones, podrá retrasar la descarga de core.js. Cuando lo haga, la página se representará más rápidamente porque el archivo core.js no se empieza a descargar hasta que la página se abre en el explorador. Esto permite al usuario ver la página y comenzar a leer el contenido antes. El escenario donde esta técnica resulta más útil es en Internet con usuarios anónimos. Por el contrario, los usuarios autenticados necesitan descargar core.js al cargar la página para este tipo de funcionalidad o elementos de la interfaz de usuario como el menú Acciones del sitio.
Realice los siguientes pasos para implementar esta técnica.
Cree una página de diseño personalizado que no use core.js. Esta página de diseño se usará con la página principal de modo que los visitantes iniciales no tendrán que esperar a que core.js se descargue inmediatamente. Tiene que ser compatible con la página principal existente, por lo que la nueva página de diseño debe tener el mismo tipo de contenido asociado que la página de diseño actualmente en uso.
Nota
De forma predeterminada, en un sitio Portal de colaboración, se especifica el tipo de contenido Página de bienvenida.
Agregue la siguiente etiqueta a la página: <SharePointWebControls:ScriptLink runat="server"/>. Esto indica al sistema que no use el archivo core.js a menos que se haga referencia a él.
Cree un control personalizado para comprobar si hay usuarios autenticados. El control será muy simple y básicamente contiene el código siguiente (que se muestra en C#):
if (HttpContext.Current.Request.IsAuthenticated) Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
En cada servidor web, coloque el control en la memoria caché de ensamblados global (GAC) y, a continuación, agregue una entrada
SafeControl
para él en el archivo web.config para la aplicación web en la que se usará.Agregue el control personalizado a la página de diseño personalizado creada en el paso 1.
Agregue un marco IFRAME a la página de diseño. Debería hacer referencia a la página que tiene el siguiente contenido:
<body> <SharePoint:ScriptLink name="core.js" runat="server" /> <script language="javascript"> DisableRefreshOnFocus(); </script> </body>
Proteja la página de diseño personalizado y publíquela.
Base la página principal del sitio en la nueva página de diseño.
Después de realizar los pasos anteriores, pruebe la página principal del sitio para comprobar que funciona. Un usuario anónimo que la visite por primera vez no debería ver una referencia a core.js en el origen de la página, pero debería acabar en la memoria caché del explorador.
Además, tenga en cuenta lo siguiente antes de emplear esta técnica:
La página maestra del sitio y la página maestra del sistema deben ser diferentes; de lo contrario, ninguna de las páginas de _layouts funcionará correctamente.
Asegúrese de que la página maestra no contiene ningún control que requiera core.js durante la carga para funcionar.
Asegúrese de que la página maestra no tiene ningún control ScriptLink que cargue core.js o haga referencia a él.
Para obtener más información y un ejemplo de código, vea el blog del equipo de administración de contenido empresarial (ECM) de Microsoft (en inglés) (https://go.microsoft.com/fwlink/?linkid=106008&clcid=0xC0A) (en inglés).
Optimización de las páginas de vistas de listas
El equipo de servicios de Microsoft ha trabajado para cuantificar y mejorar el rendimiento de los tiempos de representación de las páginas de vistas de listas. Una página de vistas de listas es la página AllItems.aspx que usan todas las listas y bibliotecas para habilitar la exploración de contenido. El tiempo de representación de esa página puede variar considerablemente según cuántas columnas estén visibles en la vista y el formato que tengan. Por ejemplo, las opciones de pantalla y la habilitación de iconos de presencia pueden afectar en gran medida al tiempo de representación. La representación de los grupos contraídos requirió mucho más tiempo que la de los grupos expandidos, y ambas fueron más lentas que no tener grupos.
Debido a este tipo de matices, es importante considerar cuidadosamente la forma en que se construyen las vistas en las páginas de vistas de listas, especialmente a través de vínculos de red lentos. Cuando se trabaja con listas que contienen una gran cantidad de datos, es importante adaptar con cuidado todas las vistas, especialmente la vista predeterminada. En general, para acelerar el tiempo de representación de las páginas de vistas de listas, se puede:
Mostrar menos columnas
Excluir todas las columnas que incluyan información de presencia
Usar un vínculo (pero no un menú Edición) para ver los detalles de elementos
En la tabla siguiente se describen las personalizaciones que reducen el tiempo necesario para representar una vista.
Elemento | Descripción |
---|---|
Tipo de vista |
Cree una vista como una vista de hoja de datos en lugar de una vista estándar. |
Vista: Límite de elementos |
Todo lo que supere 1.000 probablemente se representará lentamente. Cuando la conexión es lenta, es importante experimentar hasta encontrar el equilibrio adecuado entre la cantidad de datos que se muestran a la vez y el número de recorridos de ida y vuelta necesarios para ver todos los datos. Cuantas más filas se muestren a la vez, habrá menos recorridos de ida y vuelta, pero las páginas serán más grandes. |
Vista: Filtro |
Use [Hoy] y [Yo] para filtrar los elementos por asignación o actualización. Use los campos de estado para mostrar sólo los elementos activos en las vistas predeterminadas. |
Vista: Columnas |
Use el menor número posible de columnas. Cree una vista predeterminada con pocas columnas que permita una exploración de alto nivel que los usuarios podrán profundizar. |
En la tabla siguiente se describen las personalizaciones que aumentarán el tiempo necesario para representar una vista. Cada columna adicional aumenta ligeramente el tiempo de representación: hasta medio segundo por columna en una conexión de red rápida para una lista de 1.000 elementos. Algunas columnas requieren más tiempo, como se indica en la tabla.
Elemento | Descripción |
---|---|
Agrupar por |
La agrupación agrega HTML y JScript, lo que ralentiza la representación de las listas de gran tamaño. Hacer que todos los grupos estén contraídos de forma predeterminada en realidad aumenta aún más el tiempo de representación debido a las operaciones adicionales en el modelo de objetos de explorador. |
Columna: título vinculado al elemento con el menú de edición |
La opción "vinculado al elemento con el menú de edición" es la más larga; la opción similar "vinculado al elemento" no aumenta el tiempo de representación de forma perceptible. |
Columna: buscar usuario con presencia |
Al agregar un campo de búsqueda de usuario con presencia, se agrega código HTML para cada vínculo para abrir el menú de presencia. Además se usa ancho de banda para determinar la disponibilidad de la presencia. |
En la tabla siguiente se describen las personalizaciones que tienen un impacto relativamente pequeño en el tiempo necesario para representar una vista.
Elemento | Descripción |
---|---|
Ordenar, Totales |
Aplicar varios órdenes y totales aumentará el tiempo de representación en una cantidad perceptible, pero cada uno de ellos normalmente supone menos de un segundo para una lista de 1.000 elementos. |
Optimización del almacenamiento en caché para entornos WAN
Existen varias opciones de almacenamiento en caché en Office SharePoint Server 2007. Algunas de ellas están destinadas a mejorar el rendimiento en el proceso de representación: desde el momento en que se recibe una solicitud en el servidor hasta que la respuesta comienza a transmitirse de vuelta al equipo cliente. Aunque se trata de un aspecto importante del rendimiento general del sitio, esta sección se centra en el almacenamiento en caché en lo concerniente a lo siguiente:
La función de la configuración del servidor en el almacenamiento en caché de clientes.
El control del tamaño de los elementos que se transmiten a través de la red desde el servidor hasta el cliente.
Caché BLOB
La memoria caché BLOB es un mecanismo que sólo está disponible con las características de publicación de Office SharePoint Server 2007, lo que la convierte en candidata ideal para sitios de portales corporativos que se basan en la plantilla de sitio Portal de colaboración y sitios expuestos a Internet que se basan en la plantilla de sitio Portal de publicación. La memoria caché BLOB permite configurar directivas de almacenamiento en caché que se asocian con elementos extraídos de listas de sitios de publicación como, por ejemplo, la Biblioteca de páginas e Imágenes de la colección de sitios. Cuando el explorador en el equipo cliente encuentra una directiva de almacenamiento en caché, detecta que el elemento que está recuperando se puede guardar de forma local y no es necesario solicitarlo de nuevo hasta que la directiva de almacenamiento en caché expire. En un entorno distribuido geográficamente, esto es muy importante, ya que reduce el número de elementos solicitados y enviados a través de la red.
Cuando la memoria caché BLOB de Office SharePoint Server 2007 está activada, ocurren un par de cosas. En primer lugar, cada vez que se solicita un elemento que se puede almacenar en caché, Office SharePoint Server 2007 busca la unidad de disco duro del servidor web que recibió la solicitud para ver si existe una copia local. Si existe, el archivo se transmite directamente del disco local al usuario. Si todavía no existe en el disco local, se realiza una copia del elemento desde la base de datos de SQL donde está almacenado y, a continuación, el elemento se envía al usuario que realizó la solicitud. A partir de ese momento, todas las solicitudes de un elemento se pueden obtener directamente del servidor web hasta que el valor de almacenamiento en caché del elemento indique que ha expirado. Como resultado, mejora el rendimiento en la granja de servidores al reducir los conflictos en el servidor de base de datos.
Lo otro que ocurre es que anexa un encabezado de almacenamiento en caché al elemento cuando el elemento se envía al cliente. Este encabezado indica al explorador durante cuánto tiempo debe almacenarse en caché el elemento. Por ejemplo, si una imagen tiene un valor de almacenamiento en caché de tres días, el explorador usará la copia de la imagen que tiene en su caché local si la imagen se solicita de nuevo en los tres días siguientes: no la solicita otra vez al servidor.
Al probar su sitio para ver qué elementos están almacenados en caché y cómo se almacenan, puede usar Fiddler (en inglés) (http://www.fiddler2.com/fiddler2/) (en inglés). La captura de pantalla siguiente muestra una captura de Fiddler en un sitio de SharePoint sencillo que se usa para publicación. El sitio se creó mediante la plantilla predeterminada del sitio del Portal de colaboración. Se agregó contenido de texto adicional a la página y varias imágenes a la página maestra.
Hay varios tipos de información importantes en la aplicación Fiddler.
La columna # de la izquierda indica que había un total de 44 solicitudes HTTP realizadas desde el explorador al servidor para representar la página.
La columna de resultados muestra el código de resultado HTTP que se devuelve a la solicitud del elemento; un resultado de 200 significa que el elemento se recuperó correctamente.
La columna de dirección URL indica el elemento específico que se solicitó.
La columna de cuerpo indica el tamaño de cada elemento.
La columna de almacenamiento en caché muestra la directiva de almacenamiento en caché asociada a cada elemento. Los datos de esta columna indican que varios elementos tienen asociada una directiva de almacenamiento en caché, es decir, tienen un atributo max-age mayor que 0. Las directivas de almacenamiento en caché se expresan en segundos. Esto significa que para la página con imágenes, se configuran varios elementos para almacenarse en caché durante 365 días (60 segundos en un minuto, 60 minutos en una hora, 24 horas en un día = 60 x 60 x 24 = 86.400 x 365 = 31.536.000).
Observe que los elementos con esa directiva de almacenamiento en caché residen todos en el directorio _layouts. El motivo por el que tienen esa configuración de almacenamiento en caché es debido a la forma en que el directorio virtual _layouts/images está configurado en IIS. Cuando se crea una nueva aplicación web, Office SharePoint Server 2007 crea automáticamente varios directorios virtuales que se asignan a carpetas en los discos físicos del servidor web. Cuando se crea el directorio virtual _layouts/images, se agrega una directiva de almacenamiento en caché que se aplica a todo el directorio. La siguiente captura de pantalla muestra la configuración para el directorio en el complemento Administrador de IIS.
Dado que todos esos elementos tienen una directiva de almacenamiento en caché distinta de cero asociada a ellos, la próxima vez que se solicite la página, el explorador usará la copia del elemento de la memoria caché local del explorador en lugar de solicitarla de nuevo al servidor. La siguiente captura de pantalla muestra una instantánea de Fiddler cuando se solicita la página una segunda vez.
Como muestran los datos de Fiddler, el número de elementos solicitados se ha reducido considerablemente: de 44 a 11. Un punto importante es que el número de solicitudes realizadas puede variar en función de cómo se solicita la página. Si usa el botón Actualizar del explorador, es probable que se soliciten de nuevo todos los elementos, tanto si existe una versión del elemento almacenada en caché como si no. Por el contrario, si la página se solicita mediante un vínculo o un método abreviado, sólo se solicitarán los elementos que no estén almacenados en caché.
Otro aspecto que muestran los datos de Fiddler es que el explorador está realizando una solicitud al servidor de las otras imágenes en la página maestra que ya tiene en su memoria caché local; el código de respuesta 304 así lo indica. Significa que el explorador ha realizado una solicitud condicional de un elemento. La respuesta 304 significa que la versión en el servidor no se ha modificado respecto a la versión en el cliente, por lo que no es necesario descargarla de nuevo. Aunque el archivo no se descarga a través de la red, ha generado un recorrido de ida y vuelta al servidor para determinar que la copia local es actual. En un entorno disperso geográficamente, los recorridos de ida y vuelta son costosos, por lo que el objetivo es reducirlos tanto como sea posible. Si se agrega una directiva de almacenamiento en caché distinta de cero a cada uno de los elementos restantes (que no sea la página, que el servidor siempre devuelve), este objetivo se puede lograr. La característica de la memoria caché BLOB es la que agrega esta directiva de almacenamiento en caché.
La memoria caché BLOB se configura mediante el archivo web.config para la aplicación web en la que se usará la memoria caché. Abra el archivo web.config en un editor de texto como el Bloc de notas y busque la entrada BlobCache. De forma predeterminada será:
<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>
Los atributos usados en el elemento BlobCache
tienen los siguientes significados:
location
** **Hace referencia al lugar de la unidad de disco duro del servidor web donde se almacenarán los elementos en caché.path
Una expresión regex de los tipos de archivos que deben almacenarse en caché.maxSize
Tamaño, en GB, que puede usar la memoria caché.enabled
** **Se establece entrue
para habilitar la memoria caché BLOB.
El siguiente atributo adicional —que no se incluye de forma predeterminada— es necesario para establecer un valor de expiración del almacenamiento en caché en elementos individuales:
max-age
El tiempo en segundos que los elementos deben almacenarse en caché en el equipo cliente.
Al establecer el atributo max-age en un valor distinto de cero, los elementos que se pueden almacenar en caché tienen un valor de expiración en la memoria caché asociado a ellos de modo que el explorador ya no necesita descargar el elemento ni comprobar si tiene la versión más reciente. Por ejemplo, suponga que desea habilitar el almacenamiento en caché y asignar hasta 100 MB en el servidor web para almacenar elementos. Deben expirar una vez al día y, además de los tipos predefinidos que se almacenan en caché, también se almacenarán en caché los archivos .htc. Para admitir estos requisitos, especifique los siguientes atributos BlobCache
:
<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>
Tenga en cuenta que este cambio en el archivo web.config debe realizarse en todos los servidores web de la granja de servidores. En la mayoría de los casos, la memoria caché BLOB comenzará a funcionar inmediatamente, pero es más seguro usar el comando iisreset cuando implemente los cambios. La captura de pantalla siguiente muestra datos de Fiddler para la misma solicitud de página mostrada anteriormente, sólo que con la memoria caché BLOB habilitada como se describe.
Observe que ahora todos los elementos de la biblioteca /SiteCollectionImages tienen el código de estado HTTP 200, lo que indica que se han descargado correctamente. Además, ahora todos tienen asociada una directiva de almacenamiento en caché, que especifica que no expirarán durante un día (8.400 segundos). Si la página se solicita de nuevo, Fiddler muestra que ninguna de las imágenes se solicita de nuevo; el número total de solicitudes para obtener esa página ha pasado así de 44 a 3 y dos de esas solicitudes proceden de la negociación de autenticación NTLM que tiene lugar entre el servidor web y la aplicación cliente. La siguiente ilustración muestra los datos de Fiddler cuando la página se solicita de nuevo.
Además, tenga en cuenta lo siguiente al trabajar con la memoria caché BLOB:
Es necesario cierto esfuerzo adicional para realizar la configuración porque hay que actualizar el archivo web.config en cada uno de los servidores web. Sin embargo, las ventajas hacen que el esfuerzo merezca la pena.
Inspeccione el contenido del sitio y determine si hay otros tipos de archivo que también deban obtenerse de la memoria caché. Un buen ejemplo son los archivos .htc. Puesto que los archivos .htc se usan en la mayoría de los sitios de publicación, debería agregar este tipo de archivo a la lista de tipos de archivo que se almacenan en caché.
La memoria caché BLOB sólo funciona con elementos almacenados en bibliotecas de SharePoint; no se puede usar con el contenido en caché de otros orígenes.
Algunas listas no funcionan de forma predeterminada con los usuarios anónimos. Si hay usuarios anónimos que tienen acceso al sitio, se deben configurar manualmente los permisos para las siguientes listas de modo que los elementos que contienen se almacenen en caché:
Galería de páginas maestras
Biblioteca de estilos
Hay otras dos opciones de configuración que hay que tener en cuenta al trabajar con la memoria caché BLOB. La primera tiene que ver con vaciar la memoria caché BLOB. Si es necesario borrar la memoria caché de un sitio en particular, navegue a esa colección de sitios y haga clic en Acciones del sitio, Configuración del sitio, menú Modificar toda la configuración del sitio. En la lista de tareas de Administración de la colección de sitios, haga clic en el vínculo Caché de objetos de la colección de sitios. En la sección Restablecimiento de caché basada en disco, active la casilla Forzar a este servidor a restablecer su caché basada en disco y, a continuación, haga clic en el botón Aceptar.
Si está considerando la posibilidad de usar el hospedaje multiproceso en una única máquina en una granja de servidores de SharePoint, también tiene que tener en cuenta que, al hacerlo, la memoria caché BLOB funcionará de una manera que parece incoherente. Configurar más de un hospedaje multiproceso en una única máquina en una granja de servidores supone un problema porque sólo uno de ellos puede adquirir el bloqueo necesario para administrar la memoria caché BLOB. Como resultado, puede parecer que la memoria caché BLOB funciona de manera intermitente. El uso correcto de la memoria caché BLOB depende, por tanto, del subproceso que se encargue de la solicitud.
Compresión IIS
A diferencia de las versiones anteriores de Productos y Tecnologías de SharePoint, ahora la compresión IIS se activa automáticamente al instalar Productos y Tecnologías de SharePoint. Una vez que un sitio ha recibido la visita de unos pocos usuarios, puede comprobar que la compresión funciona si consulta el directorio %WINDIR%\IIS Temporary Compressed Files de un servidor web. Debería contener varios archivos, lo que indica que se han solicitado archivos estáticos y que IIS ha comprimido una copia de ellos y la ha almacenado en la unidad local. Cuando se solicite de nuevo el archivo, tanto si es el mismo usuario como otro distinto, la versión comprimida del archivo se obtendrá directamente de esta carpeta. Los archivos dinámicos también se pueden comprimir, pero siempre se comprimen sobre la marcha; no se guardan copias en el servidor web local.
La compresión da como resultado un ahorro considerable del ancho de banda. Por ejemplo, el archivo core.js se incluye en todas las páginas de SharePoint. Cuando no está comprimido, ocupa 257 KB; después de la compresión, el archivo ocupa sólo 54 KB sin realizar ajustes adicionales en la compresión IIS. Aunque core.js se almacenará en caché después de que el usuario visite el sitio por primera vez, este ejemplo ilustra cómo la compresión puede ayudar de forma significativa en los escenarios con un ancho de banda limitado.
Cuando se instala Productos y Tecnologías de SharePoint, el programa de instalación configura IIS para comprimir los tipos de archivos estáticos .htm, .html y .txt; también comprime los tipos de archivos dinámicos .asp y .exe. Tras inspeccionar los tipos de archivo que más se usan en su implementación, puede resultar ventajoso comprimir tipos de archivo adicionales. Por ejemplo, probablemente resulta conveniente comprimir también los tipos de archivos estáticos .css y .js; también tiene sentido comprimir los tipos de archivos dinámicos .axd y .aspx.
Para agregar un tipo de archivo estático o dinámico a la lista de tipos que se comprimirán, use el archivo adsutil.vbs que se encuentra en la carpeta %SystemDrive%\Inetpub\AdminScripts de forma predeterminada en cada servidor web. El ejemplo siguiente muestra Microsoft Windows Server 2003, incluidos los archivos css y js en la lista de tipos de archivos estáticos comprimidos:
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"
El ejemplo siguiente muestra la inclusión de los archivos .aspx y .axd en la lista de tipos de archivos dinámicos:
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"
Al cambiar los tipos de archivo que se comprimen, asegúrese de que sólo incluye archivos adecuados para la compresión. Por ejemplo, los archivos .jpg no son un buen candidato para la compresión, ya que el formato de archivo ya está comprimido de forma inherente. Además, los tipos de archivo de 2007 Microsoft Office system, como docx, xlsx y pptx no son una buena elección para la compresión porque los archivos no se obtienen directamente del servidor, sino que se enrutan a través de distintos filtros ISAPI que se usan para administrar la completa experiencia de usuario final integrada del contenido de Microsoft Office. Además, en 2007 Microsoft Office system, estos tipos de archivos están comprimidos de forma inherente.
Además de controlar los tipos de archivos que se comprimen, también es posible controlar el nivel de compresión usado en los tipos de archivos dinámicos. La cantidad de compresión usada se basa en una escala de 0 a 10. Cuanto mayor sea el nivel de compresión, más pequeños serán los archivos. Sin embargo, la desventaja es que los niveles de compresión más altos consumen más CPU, por lo que hará un mayor uso de CPU al comprimir para crear archivos más pequeños. Cuando la compresión IIS está habilitada, se configura de manera que usa un nivel de compresión 0. Históricamente, el nivel de compresión ideal con Productos y Tecnologías de SharePoint ha sido 9. Para cambiar el nivel de compresión, use el archivo de script adsutil.vbs descrito anteriormente en este artículo. El ejemplo siguiente muestra cómo cambiar el nivel de compresión a 9.
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"
Nota
Esta configuración no cambia la compresión de los archivos estáticos.
Para obtener más información, vea el artículo sobre el uso de la compresión HTTP (IIS 6.0) (https://go.microsoft.com/fwlink/?linkid=108705&clcid=0xC0A).
Combinación de la memoria caché BLOB y la compresión IIS
Al habilitar la memoria caché BLOB, puede reducir de forma significativa el número de recorridos de ida y vuelta al servidor, y el número de archivos que se envían a través de la red cuando los usuarios exploran un sitio de SharePoint. Cuando la compresión se usa junto con la memoria caché BLOB, también se reduce la cantidad de tráfico de los archivos que se envían a los clientes. Combinar ambos puede reducir en gran medida la cantidad de tráfico de red y los conflictos por los recursos de red y de servidor.
Descarga de este libro
En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión:
Vea la lista completa de libros disponibles en la página que muestra el contenido descargable para Office SharePoint Server 2007.
Vea también
Conceptos
Optimización de elementos web personalizados para la WAN
Ampliación de soluciones globales de Office SharePoint Server con software de Office Outlook 2007 y Office Groove
Soluciones globales compatibles con Office SharePoint Server