Planeamiento de la arquitectura de búsqueda empresarial en SharePoint Server
SE APLICA A:
2013 2016 2019 Subscription Edition 
SharePoint en Microsoft 365
Antes de preparar una arquitectura de búsqueda empresarial, es necesario que planee cuidadosamente una serie de aspectos. Paso a paso, le ayudaremos a planear una arquitectura de búsqueda empresarial pequeña, mediana, grande o de tamaño extra grande.
¿Está familiarizado con los componentes del sistema de búsqueda en SharePoint Server y cómo interactúan? Si consulta Información general sobre la arquitectura de búsqueda en SharePoint Server y Arquitecturas de búsqueda en SharePoint Server 2016 (o Arquitecturas de búsqueda para SharePoint Server 2013) antes de empezar, adquirirá los conocimientos necesarios sobre la arquitectura de búsqueda, los componentes de búsqueda, las bases de datos de búsqueda y la topología de búsqueda. A continuación le sugerimos algunas de las cosas que tiene que tener en cuenta al planear una arquitectura de búsqueda:
Paso 2: ¿Qué arquitectura de búsqueda de tamaño para la cantidad de contenido?
Paso 3: ¿Cuáles son los requisitos de hardware que debo contemplar?
Paso 4: ¿Cómo sé si el rendimiento de mi arquitectura de búsqueda es bueno?
Paso 1: ¿Cuánto contenido tengo?
Los recursos que debe hospedar en la granja de servidores dependen del volumen de contenido que tenga en el índice de búsqueda. Calcule el número aproximado de elementos que quiera que permitan búsquedas. Ejemplos de estos elementos son documentos, páginas web, entradas de lista de SharePoint e imágenes. Recuerde que cada entrada de una lista de SharePoint cuenta como un elemento.
Cuando haya decidido la cifra, multiplíquela por el crecimiento que crea que ese contenido va a experimentar en los próximos 12 meses.
Por ejemplo, si empieza con 12 000 elementos indexados y espera que el volumen de ese contenido se triplique en los próximos 12 meses. Debe planear 36 000 elementos que se pueden buscar.
Paso 2: ¿Qué arquitectura de búsqueda de tamaño para la cantidad de contenido?
Evaluar la envergadura de la arquitectura de búsqueda no siempre es fácil. El tamaño de la arquitectura de búsqueda depende del volumen del contenido, la tasa de rastreo, el rendimiento de las consultas y el nivel de alta disponibilidad que se necesite. Hay arquitecturas de búsqueda de ejemplo que se recomiendan usar como base para planear su propia granja de servidores. La arquitectura de búsqueda de ejemplo que escoja dependerá de la cantidad de contenido que deba permitir búsquedas:
| Volumen de contenido (SharePoint 2016) | Arquitectura de búsqueda de ejemplo | Volumen de contenido (SharePoint 2013) |
|---|---|---|
| 0-20 millones de artículos | Granja de servidores de búsqueda pequeña | 0-10 millones de elementos |
| 0-80 millones de artículos | Granja de servidores de búsqueda mediana | 0-40 millones de artículos |
| 0-200 millones de artículos | Granja de servidores de búsqueda grande | 0-100 millones de artículos |
| 0-500 millones de artículos | Granja de servidores de búsqueda de gran tamaño | No se admite |
Aunque estas arquitecturas de búsqueda de ejemplo usan máquinas virtuales, puede usar tanto servidores físicos como máquinas virtuales según la estrategia de la solución general de SharePoint Server de la arquitectura de búsqueda.
Granja de servidores de búsqueda pequeña
Hemos estimado que esta arquitectura de búsqueda puede rastrear 50 documentos por segundo y servir en el orden de 10 consultas por segundo. Si tiene hasta 20 millones de elementos en una granja de servidores de SharePoint Server 2016, la granja de servidores de búsqueda pequeña probablemente será la granja más adecuada para usted. Con una tasa de rastreo de 50 documentos por segundo, la búsqueda tarda 110 horas en rastrear 20 millones de elementos en el primer rastreo completo.
Granja de servidores de búsqueda mediana
Hemos estimado que esta arquitectura de búsqueda puede rastrear 100 documentos por segundo y servir en el orden de 10 consultas por segundo. Si tiene entre 20 y 80 millones de elementos en una granja de Servidores de SharePoint Server 2016, la granja de servidores de búsqueda mediana probablemente será la granja más adecuada para usted. Con una tasa de rastreo de 200 documentos por segundo, la búsqueda tarda 280 horas en rastrear 80 millones de elementos en el primer rastreo completo.
Granja de servidores de búsqueda grande
Hemos estimado que esta arquitectura de búsqueda puede rastrear 200 documentos por segundo y servir en el orden de 10 consultas por segundo. Si tiene entre 80 y 200 millones de elementos en una granja de Servidores de SharePoint Server 2016, la granja de servidores de búsqueda grande probablemente será la granja más adecuada para usted. Con una tasa de rastreo de 200 documentos por segundo, la búsqueda tarda 280 horas en rastrear 200 millones de elementos en el primer rastreo completo.
Granja de servidores de búsqueda de gran tamaño
Microsoft probó esta arquitectura de búsqueda y midió que puede rastrear entre 300 y 500 documentos por segundo y servir en el orden de 10 consultas por segundo. Solo SharePoint Server 2016 admite esta arquitectura de búsqueda de tamaño. Si tiene hasta 500 millones de elementos, una granja de servidores similar a la granja de servidores de búsqueda de gran tamaño adicional es un buen punto de partida. Con una tasa de rastreo de 500 documentos por segundo, la búsqueda tarda aproximadamente 300 horas en rastrear 500 millones de elementos en el primer rastreo completo.
La creación de una granja de servidores de búsqueda de este tamaño requiere que planee y ajuste cuidadosamente la granja de servidores para obtener el rendimiento que desee. Es posible que le resulte ventajoso buscar orientación de expertos. También es importante planear la copia de seguridad y restauración de una granja de servidores de búsqueda de este tamaño y cómo recuperar la granja de servidores si el centro de datos tiene una interrupción importante. Se recomienda practicar la copia de seguridad, la restauración y la recuperación.
Paso 3: ¿Cuáles son los requisitos de hardware que debo contemplar?
Ya hemos decidido el volumen de contenido y una arquitectura de búsqueda de ejemplo, así que el siguiente paso consiste en planear el hardware que va a necesitar según se describe en esta sección:
Decidir si los servidores ejecutarán de manera física o virtual
Decidir de qué manera la arquitectura de búsqueda admitirá la alta disponibilidad
Decidir si los servidores ejecutarán de manera física o virtual
Si usa una de las arquitecturas que hemos estimado para usted, ejecutará la arquitectura de búsqueda en máquinas virtuales. Tenga en cuenta también que aunque un entorno virtual es más fácil de administrar, su nivel de rendimiento a veces puede ser ligeramente inferior que el de un entorno físico. Un servidor físico puede hospedar más componentes de búsqueda en el mismo servidor que un servidor virtual. Encontrará instrucciones útiles en Overview of farm virtualization and architectures for SharePoint 2013.
También es posible ejecutar la arquitectura de búsqueda en servidores físicos. En las arquitecturas de granja de servidores de muestra, mueva los componentes de búsqueda de las máquinas virtuales en el servidor host y quite las máquinas virtuales. Cada servidor físico puede alojar hasta cuatro componentes de índice, pero solo uno de cada tipo de los demás componentes de búsqueda. Si, por ejemplo, cambia la arquitectura de búsqueda de ejemplo medio para usar servidores físicos, verá que tiene dos componentes de procesamiento de contenido en el host E. La solución consiste en quitar uno de los componentes de procesamiento de contenido. Esto funciona porque el rastreo, el procesamiento del contenido y el procesamiento de análisis dependen de la cantidad de recursos disponibles, no del número de componentes de procesamiento de contenido.
Elegir los recursos de hardware de los servidores host
Cada componente de búsqueda y base de datos de búsqueda requiere una cantidad mínima de recursos de hardware del servidor host para funcionar bien. Pero, cuantos más recursos de hardware tenga, mejor será el rendimiento de su arquitectura de búsqueda. Por ello, es aconsejable tener más de la cantidad mínima de recursos de hardware. Los recursos que necesita cada componente de búsqueda dependen de la carga de trabajo, principalmente determinada por la tasa de rastreo, la tasa de consultas y el número de elementos indizados.
Por ejemplo, al hospedar máquinas virtuales en Windows Server 2008 R2 Service Pack 1 (SP1), no puede usar más de cuatro núcleos de CPU por máquina virtual. Con Windows Server 2012 o posterior, puede usar ocho o más núcleos de CPU por máquina virtual. Después puede escalar horizontalmente con más núcleos de CPU para cada máquina virtual en lugar de escalar verticalmente con más máquinas virtuales. Configure servidores o máquinas virtuales que hospeden los mismos componentes de búsqueda, con los mismos recursos de hardware. Vamos a usar el componente de índice como un ejemplo. Al hospedar particiones de índice en máquinas virtuales, la máquina virtual con el rendimiento más débil determina el rendimiento de toda la arquitectura de búsqueda.
Almacenamiento general
Asegúrese de que cada servidor host tenga suficiente espacio en disco para la instalación base del sistema operativo Windows Server y para los archivos de programa de SharePoint Server. El servidor host también necesita espacio en disco libre para diagnósticos como los registros, las depuraciones y las creaciones de volcados de memoria, para las operaciones diarias y para el archivo de paginación. Normalmente, 80 GB de espacio en disco son suficientes para el sistema operativo Windows Server y para los archivos de programa de SharePoint Server.
Agregue almacenamiento para el espacio de registro de SQL de cada servidor de bases de datos. Si no establece el servidor de bases de datos para que realice copias de seguridad de las bases de datos con frecuencia, el espacio de registro de SQL usará mucho almacenamiento. Para obtener más información sobre cómo planear bases de datos SQL, vea Storage and SQL Server capacity planning and configuration (SharePoint Server).
El almacenamiento mínimo que necesita la base de datos de informes de Analytics puede variar. Esto se debe a que la cantidad de almacenamiento depende de cómo interactúen los usuarios con SharePoint Server. Cuando los usuarios interactúan con frecuencia, por lo general hay más eventos para almacenar. Compruebe la cantidad de almacenamiento que su arquitectura de búsqueda actual usa para la base de datos de Analytics y asigne al menos esta cantidad para su topología rediseñada.
Recursos de hardware mínimos de la granja de búsqueda pequeña
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos.
| Servidor | En hospedaje | Almacenamiento | RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones con componentes de rastreo, administración de búsqueda, Analytics y procesamiento de contenido. | A, B | 200 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidor de base de datos que tiene todos los componentes de búsqueda. | C, D | 100 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
número arábigoCon SharePoint Server 2013, la cantidad mínima de recursos necesarios es almacenamiento de 500 GB, 16 GB de RAM y cuatro núcleos de CPU.
3Con SharePoint Server 2016 también puede usar almacenamiento de 250 GB, 16 GB de RAM y cuatro núcleos de CPU, pero cada componente de índice solo puede contener 10 millones de elementos y la granja de servidores de búsqueda solo admite el mismo volumen de contenido que una granja de servidores de búsqueda de SharePoint Server 2013.
Recursos de hardware mínimos de la granja de búsqueda mediana
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos.
| Servidor | En hospedaje | Almacenamiento | RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones que tiene un componente de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones con componentes de procesamiento de contenido y Analytics. | E, F | 300 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidor de aplicaciones con componentes de rastreo, administración de búsqueda, y procesamiento de contenido. | E, F | 100 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidor de base de datos que tiene todos los componentes de búsqueda. | G, H | 400 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
número arábigoCon SharePoint Server 2013, la cantidad mínima de recursos necesarios es almacenamiento de 500 GB, 16 GB de RAM y cuatro núcleos de CPU.
3Con SharePoint Server 2016 también puede usar almacenamiento de 250 GB, 16 GB de RAM y cuatro núcleos de CPU, pero cada componente de índice solo puede contener 10 millones de elementos y la granja de servidores de búsqueda solo admite el mismo volumen de contenido que una granja de servidores de búsqueda de SharePoint Server 2013.
Recursos de hardware mínimos de la granja de búsqueda grande
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos.
| Servidor | En hospedaje | Almacenamiento | RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | A, B, C, D, E, G, H | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8 núcleos de CPU2, 3 | 1 Gbps |
| Servidor de aplicaciones que tiene un componente de índice. | A, B, C, D, E, F, G, H, I, J | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8 núcleos de CPU2, 3 | 1 Gbps |
| Servidores de aplicaciones con componentes de procesamiento de contenido y Analytics | K, L, M, N | 300 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de aplicaciones con componentes de rastreo y administración de búsqueda. | K, L | 100 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de base de datos que contienen componentes de búsqueda. | O, P, Q, R | 500 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
número arábigoCon SharePoint Server 2013, la cantidad mínima de recursos necesarios es almacenamiento de 500 GB, 16 GB de RAM y cuatro núcleos de CPU.
3Con SharePoint Server 2016 también puede usar almacenamiento de 250 GB, 16 GB de RAM y cuatro núcleos de CPU, pero cada componente de índice solo puede contener 10 millones de elementos y la granja de servidores de búsqueda solo admite el mismo volumen de contenido que una granja de servidores de búsqueda de SharePoint Server 2013.
Recursos de hardware mínimos para la granja de servidores de búsqueda de gran tamaño adicional
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos. Solo puede compilar esta granja de servidores de ejemplo con SharePoint Server 2016.
| Servidor | En hospedaje | Almacenamiento | RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de índice. | A-X | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz y 8x | 1 Gbps |
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | Y, Z | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz y 8x | 1 Gbps |
| Servidores de aplicaciones que tienen componentes de rastreo, administración de búsquedas o procesamiento de contenido | AA-AF | 100 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de aplicaciones que tienen componentes de procesamiento de análisis | AG, AH | 800 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de bases de datos que tienen bases de datos de búsqueda | AI-AL | 500 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
Planear el rendimiento del almacenamiento
La velocidad del almacenamiento afecta al rendimiento de la búsqueda. Asegúrese de que el almacenamiento que tiene sea lo suficientemente rápido como para controlar el tráfico de los componentes de búsqueda y las bases de datos. La velocidad del disco se mide en operaciones de E/S por segundo (IOPS).
El rendimiento de la búsqueda también se ve afectado por el modo en que decida distribuir los datos de los componentes de búsqueda y del sistema operativo por el almacenamiento. Una buena idea sería:
Divida los archivos del sistema operativo Windows Server, los archivos de programa de SharePoint Server y los registros de diagnóstico en las tres particiones o volúmenes de almacenamiento separados con rendimiento normal.
Almacene los datos del componente de búsqueda en una partición o volumen de almacenamiento de alto rendimiento separado.
Nota:
Puede establecer una ubicación personalizada para los datos del componente de búsqueda al instalar SharePoint Server en un host. Cualquier componente de búsqueda en el hospedaje que necesite almacenar datos, se almacena en esta ubicación. Para cambiar esta ubicación más adelante, tiene que volver a instalar SharePoint Server en ese host.
Elegir el almacenamiento
Para obtener información general sobre las arquitecturas de almacenamiento y los tipos de disco, vea Storage and SQL Server capacity planning and configuration (SharePoint Server). Los servidores que hospedan los componentes de procesamiento de índices o análisis, o bases de datos de búsqueda, requieren almacenamiento que pueda mantener una latencia baja, a la vez que proporcionan suficientes operaciones de E/S por segundo (IOPS). En las siguientes tablas se indica el número de E/S por segundo que cada una de estas bases de datos o componentes de búsqueda necesita.
Si implementa un almacenamiento compartido de tipo SAN/NAS, la carga de disco máxima de un componente de búsqueda suele coincidir con la carga de disco máxima de otro componente de búsqueda. Para obtener el número de IOPS que la búsqueda requiere del almacenamiento compartido, es necesario incluir el requisito de IOPS de cada uno de estos componentes.
Requisitos de IOPS del componente de búsqueda
| Nombre del componente | Detalles del componente | Requisitos de IOPS | Uso de volumen/partición de almacenamiento aparte |
|---|---|---|---|
| Componente de índice | Usa almacenamiento al combinar el índice y al tratar y responder consultas. | 300 IOPS por cada 64 KB de lecturas aleatorias. 100 IOPS por cada 256 KB de escrituras aleatorias. 200 MB/s para lecturas secuenciales. 200 MB/s para escrituras secuenciales. |
Sí |
| Componente Analytics | Analiza los datos localmente, en procesamientos masivos. | No | Sí |
| Componente de rastreo | Almacena el contenido descargado localmente antes de enviarlo al componente de procesamiento de contenido. El almacenamiento queda limitado al ancho de banda de la red. | No | Sí |
Requisitos de IOPS de la base de datos de búsqueda
| Nombre de la base de datos | Requisitos de IOPS | Carga típica en un subsistema de E/S. |
|---|---|---|
| Base de datos de rastreo | IOPS entre medio y alto | Tasa de rastreo de 10 IOPS por documento y segundo (DPS). |
| Base de datos de vínculo | IOPS medio | 10 IOPS por millón de elementos en el índice de búsqueda. |
| Base de datos de administración de búsqueda | IOPS bajo | No procede. |
| Base de datos de informes de Analytics | IOPS medio | No procede. |
Decidir de qué manera la arquitectura de búsqueda admitirá la alta disponibilidad
Si no está familiarizado con las estrategias de alta disponibilidad, este es un artículo que le ayudará a empezar: Creación de una arquitectura y una estrategia de alta disponibilidad para SharePoint Server. Una arquitectura de búsqueda admite la alta disponibilidad cuando las bases de datos y componentes de búsqueda redundantes se hospedan en dominios de error distintos. Todas las arquitecturas de búsqueda de ejemplo hospedan los componentes de búsqueda redundantes en servidores independientes.
Planee instalar los siguientes elementos por cada servidor host redundante de su arquitectura de búsqueda:
Red redundante
Sistemas de alimentación redundantes con cableado independiente o un sistema de alimentación ininterrumpida (UPS).
Paso 4: ¿Cómo sé si el rendimiento de mi arquitectura de búsqueda es bueno?
Antes de implementar la arquitectura de búsqueda en un entorno de producción, debe comprobar que su rendimiento es el adecuado. A continuación le pasamos una lista de los aspectos que debe comprobar:
Compruebe que los componentes de índice emplean un subsistema de E/S de almacenamiento con IOPS suficiente. Vea Comprobar el subsistema de E/S de almacenamiento.
Implemente la arquitectura de búsqueda en un entorno piloto. Asegúrese de que el entorno piloto es representativo del entorno de producción.
Compruebe el rendimiento de búsqueda del entorno piloto. Vea Comprobar el rendimiento de búsqueda.
Para obtener información general sobre las pruebas en general en SharePoint, vea Pruebas de rendimiento para SharePoint Server 2013.
Comprobar el subsistema de E/S de almacenamiento
Para comprobar el subsistema de E/S de almacenamiento, ejecute las operaciones de disco más importantes y mida el número de E/S por segundo. Puede usar la herramienta DiskSpd para ejecutar estas pruebas. Consulte DiskSpd: una herramienta de rendimiento de almacenamiento sólida.
Configuración del entorno de prueba
No es necesario configurar toda la arquitectura de búsqueda ni instalar SharePoint Server. Basta con configurar un entorno de prueba que genere una carga de trabajo realista para el subsistema de E/S de almacenamiento.
Pensemos en el almacenamiento local. Si el host A en la granja de servidores de búsqueda mediana usa un disco local, deberá instalar dos máquinas virtuales y realizar las pruebas de operación de disco en ambas al mismo tiempo.
En el caso del almacenamiento compartido, el procedimiento es distinto. Así, tendrá que hacer lo siguiente si, por ejemplo, la carga de trabajo de todos los componentes de índice en la granja de servidores de búsqueda mediana comparte el mismo almacenamiento con otras cargas de trabajo no relacionadas:
Instalar las ocho máquinas virtuales en los hosts A, B, C y D y disponer los recursos de las cargas de trabajo no relacionadas.
Asegurarse de que la carga de trabajo no relacionada se aplica al almacenamiento compartido al mismo tiempo que realiza las pruebas de operación de disco simultáneas en todas las máquinas virtuales en los hosts A, B, C y D.
Crear un archivo de prueba
Cree un archivo de prueba de 256 GiBytes mediante el comando
diskspd -c256G testfile. Este comando crea un archivo de tamaño 256 GiBytes denominado "testfile". También puede crear un archivo con otro tamaño siguiendo la sintaxis:diskspd -c<size>[K|M|G|b] <filename>Guarde el archivo de prueba en el dispositivo de almacenamiento que desea probar. Por ejemplo: en el disco duro del host A de la granja mediana.
Reinicie el servidor. Esto evitará que el almacenamiento en caché distorsione los resultados de la prueba.
Ejecutar las pruebas
Conviene medir lo siguiente:
Rendimiento de los accesos aleatorios de tamaño medio (vea las pruebas uno y dos de abajo).
Rendimiento de lectura y escritura de las transferencias de gran volumen (vea las pruebas tres y cuatro de abajo).
En la tabla siguiente se muestran los comandos DiskSpd que debe usar para ejecutar cada prueba. En todos los comandos se da por hecho que el archivo de prueba existe en el directorio actual. Cada prueba se ejecuta durante 300 segundos.
| Número de prueba | Ámbito | Get-Help |
|---|---|---|
| 1 | 64 KB de lectura [IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | 256 KB de escritura [IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | 100 MB de lectura [MB/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | 100 MB de escritura [MB/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
Resultados del ejemplo de almacenamiento en un disco local
Los resultados de ejemplo de la siguiente tabla señalan una implementación donde se usaba el 50 por ciento de la capacidad del subsistema de disco como mínimo antes de agregar el archivo de prueba.
La controladora y los ejes del disco influyen mucho en estos resultados.
Si realiza la prueba en discos vacíos, obtendrá unos resultados elevados, ya que el archivo de prueba estará en las mejores pistas de todos los ejes. Esto puede duplicar o incluso triplicar el rendimiento. Obtendrá resultados altos muy poco realistas si comprueba un disco duro que optimiza los accesos lejanos en el espacio de almacenamiento sin inicializar o en almacenamiento que solo contiene ceros (por ejemplo, archivos VHD/VHDX dinámicos). En este caso, use un archivo de prueba muy grande que contenga datos reales, en lugar de generar un archivo de prueba sintética mediante comandos DiskSpd.
| Diseño del disco | Prueba 1 | Prueba 2 | Prueba 3 | Prueba 4 | |
| IOPS mínimo recomendado en operaciones cotidianas | 300 | 100 | 200 | 200 | |
| 4 NLSAS a 7200 RPM y 1 TB en RAID5 en una controladora RAID Dell H710 (64 KB de tamaño de sección, 64 KB de tamaño de bloque) | 1181 | 206 | 284 | 296 | |
| 8 NLSAS a 7200 RPM y 1 TB en RAID5 en una controladora RAID Dell H710 (64 KB de tamaño de sección, 64 KB de tamaño de bloque) | 2082 | 337 | 610 | 645 | |
| 16 NLSAS a 7200 RPM y 1 TB en RAID5 en una controladora RAID Dell H710 (64 KB de tamaño de sección, 64 KB de tamaño de bloque) | 3763 | 595 | 1173 | 1181 | |
| 16 NLSAS a 7200 RPM y 1 TB en RAID50 (2x8) en una controladora RAID Dell H710 (64 KB de tamaño de sección, 64 KB de tamaño de bloque) | 3613 | 545 | 1139 | 1164 | |
| 16 NLSAS a 7200 RPM y 1 TB en RAID10 en una controladora RAID Dell H710 (256 KB de tamaño de sección, 64 KB de tamaño de bloque) | 4030 | 1146 | 970 | 775 | |
| 4 SSD de 800 GB SmartStorage Optimus en RAID5 en una controladora RAID Dell H710 (64 KB de tamaño de sección, 64 KB de tamaño de bloque) | 32385 | 3781 | 1714 | 1319 | |
| 4 SSD de 800 GB SmartStorage Optimus en RAID0 en una controladora RAID Dell H710 (256 KB de tamaño de sección, 64 KB de tamaño de bloque) | 31747 | 7149 | 1643 | 1798 |
Comprobar el rendimiento de búsqueda
A continuación le pasamos una lista de los aspectos que debe comprobar al probar su arquitectura de búsqueda:
Elegir el contenido donde realizar las pruebas
Elija contenido que represente fielmente su contenido de producción. Si escoge contenido pensado únicamente para realizar pruebas, asegúrese de que tiene tipos de elementos distintos, y no un solo elemento duplicado varias veces. El motivo de esto es que el procesador de consultas invertirá tiempo en detectar los elementos duplicados, lo que afecta al rendimiento de la búsqueda y hace que los resultados que obtenga no sean representativos de un entorno de producción.
Prepare uno o varios orígenes de contenido para rastrear el contenido. Confirme que dispone del correspondiente acceso a la red y a la cuenta de usuario.
Elegir términos y frases para comprobar el rendimiento de las consultas
El número de resultados que se obtiene en una consulta se denomina recuperación.
Para comprobar el rendimiento de las consultas, antes debe crear un conjunto de términos y frases para usarlos como consultas. Como alternativa, recopile consultas de una instalación existente. Procure que este conjunto incluya términos y frases con alta y baja recuperación y que dichos términos y frases sean relevantes en su entorno.
Ejemplos
Si busca un número de producto en un catálogo de productos, es probable que solo haya un número para un producto. Por lo tanto, obtendrá los resultados de la búsqueda rápidamente. Esto es poca recuperación.
Si busca un término común (como "presentación") en la intranet de una compañía, seguramente aparezcan muchos resultados y tarden más en hacerlo. Esta sería una recuperación alta.
Si su contenido está relacionado, por ejemplo, con recursos humanos, emplee los términos de búsqueda relativos a dicha área.
Medir el rendimiento de búsqueda
SharePoint Server recopila medidas de rendimiento de búsqueda en los informes de estado de rastreo e informes de estado de consulta. Puede encontrar estos informes en Administración central, en Administración de búsquedas.
Resulta útil medir el rendimiento de búsqueda con una carga sintética primero y, luego, con un conjunto reducido de usuarios y contenido dinámicos. Cuando se usan usuarios y contenido dinámicos, se puede apreciar el rendimiento de la arquitectura de búsqueda. Si el contenido aumenta a mayor velocidad de lo deseado, puede que no esté de más sopesar el uso del siguiente tamaño de arquitectura de búsqueda. O bien, si los usuarios están más activos de lo previsto, se recomienda aumentar la cantidad de espacio de almacenamiento de la base de datos de análisis.