Search API:
Si se puede usar en sitios grandes PERO es recomendable usarlo junto a Apache Solr o Elasticsearch, para mejorar el rendimiento se debería deshabilitar el módulo search del core de Drupal (a menos que se esté usando, aunque no se debería usar junto a search API), también deberían removerse cualquier otro módulo de búsqueda a menos que sea absolutamente necesario.
Search API Index options
Esta bien que esté activada esta opción si es un sitio pequeño, no se recomienda en sitios grandes sin otros motores de búsqueda, si se usa junto a Solr o Elasticsearch el desarrollador del módulo explico en la Drupalcon del 2019 que el rendimiento se ve afectado más con Solr, en sitios grandes tener esta opción activada junto con alguno de estos dos motores de búsqueda (Apache Solr o Elasticsearch) debería evaluarse si es necesaria que se mantenga activada, dependerá de las necesidades del cliente y su infraestructura, estos motores de búsqueda no tienen problemas en manejar grandes cantidades de información, lo que puede afectar su rendimiento y para lo que no están tan preparados es cuando tiene que recibir nueva información de manera constante y en periodos cortos de tiempo.
El punto en contra que se mencionó de desactivarlo es que si se crea un nodo y se indexa, y luego se despublica seguirá apareciendo en los resultados de búsqueda hasta que se corra el siguiente CRON, Search Api muestra el contenido despublicado por defecto si no queremos que se muestre ese contenido a usuarios no autorizados o a algún usuario con un rol determinado nos recomiendan controlar estos con algunos de estos 2 módulos Content Access o Entity status (este último solo para Drupal 7)
Search API resumen:
- Desactivar el search del core (y otros módulos de búsqueda a menos que sean necesarios).
- Index Options:
- Activado en sitios pequeños.
- Desactivado en sitios grandes sin Solr o Elasticsearch.
- Si cuenta con Solr o Elasticsearch se puede activar pero se resentirá un poco el rendimiento, evaluar si es necesario para el proyecto, así como también si su infraestructura no tendrá problemas al manejar esto.
- Si se desactiva algunos resultados de búsqueda se pueden mostrarse así estén eliminados o despublicados, hasta que se corra el próximo CRON:
Simple XML sitemap
Algo curiosos de este módulo es que si revisamos la carpeta dentro de contrib se llama simple_site-map, en sitios con muchas URLs la generación del sitemap puede usar muchos recursos del servidor al regenerar el sitemap, la configuración por defecto de este módulo es que corra junto al CRON y el intervalo es con cada ejecución del CRON, este módulo cuenta con menú de configuración en /admin/config/search/simplesitemap/settings la opción "Regenerate the sitemaps during cron runs" debe estar marcada a menos que se vaya a generar el sitemap de manera manual o vía drush, y en el intervalo tiene las opciones, en cada ejecución del CRON, 1, 3, 6, 12 horas o 1, 2, 3, 4, 5 ,6 días y 1 semana, si el sitio es muy grande y el servidor no es tan potente o tiene una capacidad límitada debería configurarse para que se renueve 1 vez por semana.
Para mejor rendimiento debería estar marcada la opción "Exclude duplicate links" y en "Sitemap generation max duration" viene por defecto en 10 y la opción "Entities per queue item" trae por defecto 50, estas 2 opciones afectan la velocidad de generación del sitemap podemos dejarlos por defecto, o para tener una mejor idea de como ajustar esas dos opciones podemos correr este comando de drush en un ambiente de producción
drush scr --uri http://example.com modules/contrib/simple_sitemap/tests/scripts/performance_test.php
o este otro en un ambiente local
drush scr --uri http://localhost/drupal/project modules/contrib/simple_sitemap/tests/scripts/performance_test.php -- generate 500
Este módulo también cuenta con dos sub módulos uno para indexar las vistas "Simple XML Sitemap (Views)" (sólo funciona con las vista de tipo página), otro para enviar el sitemap directo a los buscadores Google y Bing, se llama "Simple XML Sitemap (Search engines)" y cuenta con configuración del intervalo en el que se mandan el o los sitemaps similar a la configuración de generación del sitemap .
Google nos dice "Sea cual sea el formato que se use (admite XML, RSS, MRSS, Atom 1.0 y txt), los sitemaps no pueden tener un tamaño superior a 50 MB sin comprimir ni incluir más de 50.000 URLs. Si tienes un archivo más grande o con más URLs, tienes que dividirlo en varios sitemaps. En ese caso, puedes crear un índice de sitemap (un archivo que lleva a una lista de sitemaps) y enviar solo ese archivo a Google. Puedes enviar varios sitemaps o archivos de índices de sitemaps a Google".
La primera vez que se manda el sitemap a Google este lo registra y en teoría no debería ser necesario volver a mandarlo, porque mandara automática y periódicamente a sus crawlers a buscar cambios en el sitemap. Pero si queremos o las necesidades del proyecto son que se indexe lo antes posible podemos usar el sub-módulo que remite automáticamente los sitemaps a los buscadores
Simple XML sitemap resumen:
- Para sitios pequeños puede dejarse la configuración por defecto que corra con cada CRON.
- Para sitios grandes con muchas URLs 1 vez a la semana será suficiente. A menos que se necesite expresamente que se indexe/agregue antes.
- En opciones avanzadas podemos dejar todo por defecto, a menos que sea un sitio con muchas URLs y necesitamos una configuración específica, para ese caso usar el comando de drush y ajustar los valores acordemente.
- Siempre activada la opción ”Exclude duplicate links”.
CRON
En la mayoría de los casos se deberá dejar como viene por defecto (corre cada 3 horas, pero puede variar automaticamente segun el trafico que recibe el sitio), pero según la documentación deberíamos cambiar la configuración si tenemos mucho o muy poco tráfico para que se adapte a nuestras necesidades, la manera más fácil de usar el CRON es con Drupal pero esto tiene 2 puntos en contra, solo corre cuando procesos de Drupal hacen la petición y consume más recursos, si quisiéramos deshabilitar el CRON de Drupal porque lo correremos externamente, o queremos hacer pruebas, lo podremos hacer de 3 maneras:
- La forma recomendada es desactivar el módulo "automated cron" que es parte del core.
- Una forma de desactivar el CRON de manera temporal es mediante la configuración en /admin/config/system/cron y cambiar el valor a nunca.
- Otra opción más avanzada es mediante el settings.php agregando la siguiente línea
$config['automated_cron.settings']['interval'] = 0;
esto hará que cuando se visite /admin/config/system/cron salga marcada la opción nunca y no se pueda cambiar.
También podríamos usar un script para que se corra en el servidor, cPanel también tiene como configurar un CRON job ,o podemos usar servicios web para esto como EasyCron o Cronless que cuentan con planes gratuitos y de pago, de esta forma se puede tener más control sobre la configuración de CRON y usará menos recursos . O manualmente podríamos correr CRON con drush.
CRON resumen:
- La configuración por defecto debería ser que se ejecute cada 3 horas.
- Desactivar la opción de "Registro de CRON detallado".
- Como hemos visto antes esto puede variar, así que podemos disminuir el intervalo que se toma para correr si tenemos alto tráfico y tenemos recursos suficientes en el servidor, si se cuenta con menos recursos en el servidor podemos hacer que CRON se corra menos veces al día.
- Idealmente se desactiva en Drupal y se correría directamente en el servidor.
Me pareció interesante el artículo
Añadir nuevo comentario