Se encuentra en:
Pautas para el manejo de la escalabilidad
LIBP-0134 (Libro de pautas)
- Área: Rendimiento en Drupal
- Tipo de pauta: Directriz
- Carácter de la pauta: Obligatoria
Se deben tener en cuenta las formas de escalar soluciones basadas en Drupal, antes de alcanzar una situación límite que provoque una degradación del rendimiento.
Conociendo las características de éxito de Drupal en cualquier proyecto que requiera de procesos de gestión de contenidos e interacción de usuarios en una comunidad, una de las mayores dificultades comienza cuando se empieza a tener un éxito notorio y se rebasa un umbral de visitas significativo. En este punto las cosas pueden empezar a ir realmente mal en lo que se refiere al rendimiento.
La instalación por defecto de Drupal no soportará esa cantidad de tráfico y habrá que redistribuir la carga de un solo servidor a varios. Hay que mejorar la escalabilidad de la aplicación. Los objetivos de una buena escalabilidad en Drupal deben considerar que:
- En el caso de demandar más funcionalidad para que una aplicación sea más útil se requiere que las piezas de Drupal que has integrado para tu proyecto puedan seguirse extendiendo de forma simple, que puedas actualizar a nuevas versiones sin tener que reescribir mucho código y que puedas beneficiarte de incluir nuevas piezas externas o desarrolladas por tu equipo sin mayor dificultad.
- Para el aumento del almacenamiento de datos o peticiones diarias, se tiene que prever que todo servidor tiene unos límites y por tanto si las expectativas de crecimiento superan las capacidades reales de la arquitectura de los servidores hay que poner más servidores en el momento oportuno y con la configuración correcta y apuntalar el punto de mayor riesgo de la arquitectura que suele ser la base de datos.
A continuación se ofrece un conjunto de pautas y buenas prácticas que pueden solucionar los problemas de escalabilidad.
Pautas
| Título | Carácter |
|---|---|
| Implementar capas de caché | Recomendada |
| Optimizar la base de datos | Recomendada |
| Prevención de bloqueos de base de datos | Recomendada |
| Externalizar la búsqueda a una aplicación especializada | Recomendada |
Implementar capas de caché
Es recomendable que se implementen capas de caché para todos los contenidos que no cambia. En el caso que tengamos sistemas que generen una noticia o un post no se actualiza después de su publicación, si lo cacheamos, se ahorran muchos recursos si Drupal guarda ese contenido renderizado en html en un motor de cache en lugar de generar en cada petición cientos de consultas a la base de datos para volver a renderizarlo.
Optimizar la base de datos
Es recomendable implementar optimizaciones de configuración para el rendimiento de base de datos e índices. En ocasiones las consultas son repetitivas, lo que facilita una mejora de rendimiento si se optimizan algunos parámetros de la base de datos, en función de las tablas involucradas. Se pueden escribir índices estratégicos que reduzcan el escaneo de filas y que mejoren su rendimiento. Se deben seguir las siguientes recomendaciones:
- Blindar los recursos físicos del sistema, para ello es necesario asegurar que no se sobrecarga la base de datos mas allá de lo que puede soportar. Evitando de esta manera que deje de responder y se desborde y protegiendo la aplicación de caídas significativas de rendimiento. La fórmula para calcular las máximas conexiones que podemos servir y por tanto, las consultas simultáneas que se pueden encolar se determina con las siguientes variables:
global_buffer + (thread_buffer * max_connections)
- Activar la caché de la base de datos para que las consultas repetitivas se resuelvan desde los resultados almacenados en la caché.
- Monitorizar con el histograma de consultas dónde podremos tener una visión global de las consultas que más tiempo están tardando en resolverse y por tanto, podremos analizarlas a fondo para determinar los problemas de ejecución.
- Implementar una infraestructura de cluster de servidores en relación esclavo y maestros (escritura/lecturas) con balanceo a nivel de Drupal, para repartir la masa crítica de lecturas en varios servidores del cluster que se encuentran replicados y que evitan la sobrecarga de un solo punto de nuestra arquitectura.
Prevención de bloqueos de base de datos
En algunas ocasiones no se llega al límite de la base de datos, sino que se producen errores y desviaciones entre escrituras y lecturas respecto a la media, y las configuraciones por defecto nos empiezan a degradar el funcionamiento. Un ejemplo común es que las tablas están pensadas para recibir el 95% de lecturas y el 5% de escrituras y si se rompe esa regla, se empezarán a producir bloqueos de consultas que pondrán al límite la cola de consultas de la base de datos. Hay que controlar estas situaciones.
Externalizar la búsqueda a una aplicación especializada
Una de las funcionalidades que degrada los recursos de la base de datos y que pone en riesgo la estabilidad de nuestra aplicación es la búsqueda que viene integrada dentro del núcleo de Drupal. La función de búsqueda de contenidos y funciona bastante bien cuando el volumen de datos no supera los 10.000 nodos y no tiene mucho tráfico. Sin embargo, los índices que usa Drupal se almacenan en base de datos y son una parte fundamental de la sobrecarga de consultas. El módulo “Search” que viene en el paquete oficial, es un buen módulo cuando el volumen de datos no supera los 10.000 nodos y máximo 1000 visitas por día. La indexación de los nodos está almacenada en la tabla “search_index” de la base de datos y como consecuencia cada búsqueda le genera consultas costosas de procesar. La solución es implementar un motor de búsqueda independiente que puede ayudarnos rápidamente a ahorrar muchas consultas a nuestra base de datos.
Es recomendable considerar la posibilidad de externalizar esta funcionalidad. Existen sistemas especializados (por ejemplo Apache-solr que se integra perfectamente en Drupal). Ademas podemos utilizar este potencial no solo para las búsquedas sino también para servir cualquier tipo de listado o cruces de taxonomías, ya que los IDS (tids) de taxonomías se indexan como un término más de búsqueda ayudando a evitar los costosos joins de las tablas de taxonomías de Drupal, y canalizando esa carga a un cluster de servidores de búsqueda que aligerará la carga del atareado servidor de base de datos.
