Relevanssi hospedaje tamaño para el índice, no sólo los puestos.
Relevanssi construye su propio índice dentro de MySQL, y en un sitio de contenido-pesado que índice es rutinariamente más grande que cada post que ha escrito. La base de datos tiene que ser configurada para él.
Todo lo que un índice respaldado por bases de datos pide un host.
Relevanssi no llama a un servicio de búsqueda. Cada consulta y cada reconstrucción sucede en su base de datos, lo que hace que este sea un problema de afinación MySQL.
Un índice que se ajusta a la memoria
La piscina de amortiguación InnoDB es tallada para mantener el índice Relevanssi junto al resto del conjunto de trabajo, por lo que una búsqueda lee de memoria en lugar de tirar páginas de índice fuera de disco una consulta a la vez.
Recompilados que terminan
Un reindex completo en un sitio grande superará cualquier solicitud del navegador. El nuestro se ejecuta desde WP-CLI con el techo de ejecución elevado, por lo que el trabajo termina en lugar de morir a mitad de camino y dejar un índice parcial.
Páginas de búsqueda mantengan dinámica
Las páginas de resultados son per-query y a menudo per-user, por lo que se mantienen fuera de la caché de la página. Las costosas miradas detrás de ellos se caché en Redis en lugar, que es donde la repetición en realidad es.
Sala para documentos largos
Indización de postes largos, campos personalizados y texto adjunto significa escribir grandes filas. Los límites de paquete y fila se elevan para que los escribas tengan éxito en lugar de fallar silenciosamente en el índice medio.
Respaldos que conocen el índice es reconstruible
El contenido se respalda por la noche y se reproduce de origen. El índice se puede regenerar de él, por lo que un restaurador no depende de haber capturado una copia consistente de una tabla que cambia constantemente.
Saber que el índice es actual.
Un índice de búsqueda es invisible hasta que alguien busque el post que publicaste esta mañana y no encuentra nada. Estas son las cosas que vale la pena ver.
- Acceso de administración de un clic, sin contraseñas compartidas
- Tamaño del índice rastreado contra la piscina de amortiguación
- Actualizaciones de enchufe y núcleo con el estado de cada punto
- Restaurar cualquier copia de seguridad diaria del panel de control
Busquen que las respuestas antes de que lo repitan.
Las consultas de Relevanssi no pueden ser caché a nivel de página, por lo que su velocidad se decide por completo si el índice está en memoria cuando la consulta llega.
Lo que cambiamos para Relevanssi
Estos difieren de un sitio estándar de WordPress en el mismo plan, y cada uno de ellos existe porque el índice de búsqueda vive en su base de datos en lugar de en un servicio separado.
| Ajuste | Qué hacemos | Por qué |
|---|---|---|
| Piscina de amortiguación InnoDB | Plancha para mantener el índice Relevanssi además del conjunto de trabajo normal | El índice en un sitio con contenido pesado supera con frecuencia el tamaño de la tabla de publicaciones en sí, y una vez que ya no se ajusta a la memoria cada búsqueda comienza a leer páginas índice de disco en lugar de RAM. |
| max_allowed_packet | Criado bien por encima de la predeterminación para los escritos índice | La indexación de postes largos junto con campos personalizados y el contenido de adjunto produce declaraciones individuales mucho más grandes que una instalación MySQL por defecto acepta, y las superficies de rechazo como contenido que simplemente nunca es posible encontrar. |
| Reeducación del índice | Ejecutar a través de WP-CLI con el techo de ejecución levantado, nunca de una solicitud de página de administrador | Un reindex completo en un archivo grande funciona durante muchos minutos, por lo que el desencadenamiento del navegador significa una solicitud que muere en parte y deja el índice que contiene algunos del sitio y ninguno del resto. |
| Páginas de resultados de búsqueda | Excluido del caché de la página; las búsquedas subyacentes caché en Redis | Cada página de resultado es específica para una cadena de consulta y a menudo para los permisos de un usuario, por lo que cachear la página es inútil mientras que cache la consulta detrás de ella elimina el trabajo repetido. |
| Supervisión del crecimiento del índice | Tamaño de tabla de índice rastreado y alertado contra la piscina configurada | El índice crece con el archivo en lugar de con el tráfico, por lo que un sitio que ha sido rápido durante un año se degrada gradualmente sin cambio en los visitantes y nada en el gráfico de tráfico para explicarlo. |
Precios claros y sencillos.
Todos los planes incluyen migración gratuita, copias diarias, SSL y soporte 24/7.
- 1 sitio WordPress
- 10 GB de almacenamiento NVMe
- SSL gratis
- Copias de seguridad diarias
- Despliegue con un clic
- Soporte por tickets
- 5 sitios WordPress
- 50 GB de almacenamiento NVMe
- SSL gratis
- Copias de seguridad diarias
- Despliegue con un clic
- Soporte prioritario por tickets
- 20 sitios WordPress
- 200 GB de almacenamiento NVMe
- SSL gratis
- Copias de seguridad diarias
- Despliegue con un clic
- Soporte dedicado
Preguntas frecuentes.
¿Por qué mi búsqueda de Relevanssi es más lenta de lo que solía ser?
¿Cuánto tiempo lleva un índice completo?
¿Debería usar Relevanssi o ElasticPress?
¿Pueden las páginas de resultados de búsqueda ser caché?
¿Mis respaldos incluyen el índice de búsqueda?
Ejecute Relevanssi con una base de datos que se ajuste al índice.
Migración libre, una piscina de amortiguación tamaño para su archivo, y reconstruye eso completo.