PDF de programación - Construyendo proyectos escalables con Drupal

Construyendo proyectos
escalables con Drupal

Pablo Cerda
Director de desarrollo de ideup!
www.ideup.com
Drupalcamp Spain 2010

De qué va el tema

Crónicas de un programador que heredó un
proyecto (lanetro.com) que no seguía las
buenas prácticas de Drupal y petaba por
todos lados.

Narraremos cómo reconducimos y

refactorizamos un proyecto que parecía ir
directo al fracaso y que al final se ha
convertido en un caso de éxito de una
aplicación bien hecha en Drupal.

Drupalcamp Spain 2010

Velocidad de evolución
• Los servicios web que utilizamos a diario

(Google, Flickr, Facebook, etc.) evolucionan
rápidamente.

• El usuario se vuelve más experto.
• Para permanecer líderes, no hay otro camino

que reinventarse constantemente.

• Reinventarse significa invertir en un equipo
tecnológico que sea capaz de mantener lo
que funciona y expandirlo de forma
inteligente.

Drupalcamp Spain 2010

Cuidado con perder el control

Es difícil ver el punto de ruptura
entre una aplicación sostenible o
no. El síntoma es que de pronto
es muy costoso corregir errores o
añadir funcionalidades.

Drupalcamp Spain 2010

Miles de cabezas piensan más

que unas cuantas

! Muchas de las

funcionalidades que
quieres desarrollar ya
están hechas.
¡Reutilízalas!
! Muchos de los

desarrolladores que
colaboran con Drupal
tienen décadas de
experiencia. ¡Benefíciate!
! ¿Podrá un equipo de 1 o
2 programadores juniors
hacerlo mejor?

Drupalcamp Spain 2010

Cimienta tus conocimientos de

Drupal

! Este libro es una

lectura fundamental
para cualquiera que
desee hacer cosas
serias y bien hechas
con Drupal.

! En Abril sale la

edición para Drupal 7.
¡Estad atentos!

Drupalcamp Spain 2010

¡Que se convierta en éxito no en

pesadilla!

! Una instalación básica de

Drupal está bien para
empezar.

" La dificultad comenzará

cuando se rebase el
umbral de las 5,000
visitas diarias.

! ¡Ha llegado el momento

de escalar!

Drupalcamp Spain 2010

¡Drupal puede escalar, y mucho!

Definiendo escalabilidad

!El sistema puede acomodarse al

incremento de su uso.

!El sistema puede acomodarse al

incremento de su volumen de datos.

!El sistema es sostenible.

- Cal Henderson, Building Scalable Websites
(O’Reilly)

Drupalcamp Spain 2010

Definiendo rendimiento

• Tiempo de respuesta - umbral entre que se

solicita y se completa una petición.

• Tiempo de carga de página - tiempo de todos

los componentes que se descargan para
renderizarse en el navegador.

• Sus requerimientos pueden variar

dependiendo de la audiencia.

Drupalcamp Spain 2010

¿Hasta que punto mejorar el

rendimiento?

! Lo suficiente para complacer la impaciencia
del usuario y siempre por encima de nuestra
competencia.

! Llegar al punto óptimo es muy costoso, hay

un umbral donde sólo se puede mejorar a
costa de pasar mucho tiempo reescribiendo
código con algoritmos más complejos.

! Pero… El precio actual de los servidores es

menor que el de desarrolladores.

Drupalcamp Spain 2010

Arquitectura de servidores en

lanetro

APPLICATION-CMS

DRUPAL

PHP

APACHE

Memcached

LINUX (debian)

Apache Solr

Serv. App. Jetty
LINUX (debian)

MySQL
RAID 0+1

LINUX (debian)

nagios

cacti

Análisis logs apache

LINUX (debian)

Drupalcamp Spain 2010

El punto clave para escalar

Drupal es la BD

Por su estructura modular y de sobre
escritura de funciones y consultas,
Drupal no es muy amigable con los
motores de base de datos.

Cada módulo necesita realizar muchas
consultas sobre las tablas base de
Drupal (node, users, taxonomy, etc.)
que resultan en una sobrecarga.

Drupalcamp Spain 2010

¡Hay que liberarle carga a la BD!

! Cachear todos los contenidos que no

cambian. El motor de almacenamiento por
excelencia es Memcached.

! Configurar la BD para un rendimiento óptimo,

no usar configuración por defecto.

! Prevenir los bloqueos de base de datos. En
muchos escenarios no se ha llegado al límite
real de la capacidad de la base de datos si no
que se ha desviado la relación entre
escrituras y lecturas.

Drupalcamp Spain 2010

Caché del núcleo de Drupal

• Un gran problema de la caché del núcleo de
Drupal es que no tiene reglas personalizables
y que no es consistente con usuarios
autenticados. ¡Lo advierte la cache agresiva!

• Si lo has hecho bien, muchas piezas estarán

desarrolladas como bloques y podrás
beneficiarte de la caché de bloques.
http://drupal.org/project/blocktools

Drupalcamp Spain 2010

Authcache, una cache mejorada

• Ofrece la funcionalidad de cachear para usuarios
anónimos o autenticados lo que permite a Drupal
servir las peticiones en 1-2 milisegundos y liberar
la carga de los servidores.

• No interfiere con módulos de estadística de

Drupal pues provee un hook AJAX que dispara
las funciones con las que damos seguimiento a
ciertos eventos. hook_exit por ejemplo.

• Permite crear reglas complejas de cache según

expresiones regulares de rutas (paths).

Drupalcamp Spain 2010

http://drupal.org/project/authcache

Drupalcamp Spain 2010

Invalidación de cache

• La cache es útil siempre y cuando no

represente un desfase de la información, si
está obsoleta hay que invalidarla.

• Caché browser es un módulo que nos

permitirá navegar por un inventario de cache
y resetear de forma manual, evitando el
brusco y nada recomendable reseteo global.
http://drupal.org/project/cache_browser

Drupalcamp Spain 2010

Cache Browser, un navegador de

cache

Drupalcamp Spain 2010

ApacheSolr nos salvó la vida

Drupal tiene integrada en el

núcleo la función de
búsqueda de contenidos
pero cuando supera los
50,000 nodos e
incrementa su tráfico es
una gran carga para la
BD.

ApacheSolr es la mejor

solución de búsqueda,
que además puede servir
para generar cualquier
tipo de listado o consultas
de taxonomías.

Drupalcamp Spain 2010

ApacheSolr es extensible

! El módulo Apache Solr Search Integration ha tenido
gran aceptación por la comunidad de Drupal y han
surgido múltiples complementos.

! Se puede disponer de filtrado dinámico de resultados

(facet search) con Apache Solr AJAX.
http://drupal.org/project/apachesolr_ajax

! Webservice para realizar búsquedas de los contenidos

gestionados con Drupal e integrarlos con otras
aplicaciones.
http://drupal.org/project/solr_service

Drupalcamp Spain 2010

ApacheSolr es escalable

!Se pueden disponer de
múltiples servidores de
lectura balanceados, lo
que permite crecer de
forma simple.

Drupalcamp Spain 2010

Prevención de bloqueos de BD

• Se ha desviado la relación entre escrituras y

lecturas respecto a la media y las configuraciones
por defecto de Mysql nos empiezan a degradar el
funcionamiento.

• Un ejemplo común es que las tablas MyIsam están

pensadas para recibir 95% de lecturas y 5% de
escrituras.

! Hay que buscar métodos de escritura más

eficientes como tablas InnoDB o Heap.

Drupalcamp Spain 2010

Optimización backend

!Identificar los datos que no cambian y que

pueden guardarse en cache para no
requerirlos repetidamente a la BD.

!Optimizar las consultas para asegurar que

siempre se resuelven de la forma más
rápida.

!Verificar que no faltan índices.

Drupalcamp Spain 2010

Una consulta SQL de muerte

SELECT qc.enid AS ID_EVENTO, qc.snid AS ID_SITIO,
ns.title AS NOMBRE_SITIO, ne.title AS TITULO_EVENTO,
vote.value as RANKING,
fes.fecha AS FECHA,
IF(res.horario IS NULL OR TRIM(res.horario)='','--',res.horario) AS HORA,
IF(res.precio IS NULL OR TRIM(res.precio)='','--',res.precio) AS PRECIO,
IF(res.titular IS NULL OR TRIM(res.titular)='',ne.title, res.titular) AS TEXTO_EN_TITULO_DESPLEGABLE,
IF(res.resumen_alternativo IS NULL OR TRIM(res.resumen_alternativo)='',ln_e.resumen, res.resumen_alternativo) AS COMENTARIO_EN_DESPLEGABLE,
tde.name AS CATEGORIA_EVENTO
FROM (". $lQueryCentral.$lJoins.$lWheres. ") qc
INNER JOIN {node} ns ON qc.snid = ns.nid
INNER JOIN {node} ne ON qc.enid = ne.nid
INNER JOIN {ln_evento} ln_e ON ne.vid = ln_e.vid
INNER JOIN {term_node} tne ON ne.vid = tne.vid
INNER JOIN {term_data} tde ON tne.tid = tde.tid
INNER JOIN {ln_rel_evento_sitio} res ON qc.relES_id = res.id
INNER JOIN {ln_fecha_evento_sitio} fes ON qc.relES_id = fes.relid
LEFT JOIN {votingapi_cache} vote ON vote.content_type='node' AND function='average' AND vote.content_id=qc.enid
WHERE fes.fecha >= %d AND fes.fecha <= %d AND tde.vid = %d

Drupalcamp Spain 2010

Una consulta compleja pero razonada
SELECT DISTINCT ncs.nid as id

FROM {node_comment_statistics} ncs WHERE
EXISTS
(
SELECT res.enid FROM {ln_rel_evento_sitio} res,
{term_node} tne, {leftandright} lre, {term_node} tns,
{leftandright} lrs
WHERE ncs.nid=res.enid AND res.enid=tne.nid
AND res.snid=tns.nid
AND tne.tid=lre.tid AND tns.tid=lrs.tid
AND lre.vid = 22 AND lre.lft >= %d AND lre.rgt <= %d
AND lrs.vid = 11 AND lrs.lft >= %d AND lrs.rgt <= %d
)

ORDER BY ncs.comment_count DESC LIMIT 0,50

Drupalcamp Spain 2010

Optimización frontend

• Yslow Firefox addon

http://developer.yahoo.com/performance/rules.ht
ml

• Minimizar las peticiones http (agregación de

archivos, js, css, etc.)

• Orden de carga (css al principio, scripts al final)...
• CSS sprites, que los iconos se agrupen en una

sola imagen para hacer una sola carga http.

• Muchas otras.

Drupalcamp Spain 2010

Optimizaciones en servidores

frontales

! Apache mod_gzip - ahorro de trasferencia y

reducción de tiempo de descarga

! Cache opcode con APC, eAccelerator, Xcache,

etc.

! Limitar la variable MaxClients para que no

sobrepase el uso máximo de memoria de cada
frontal.

! Hacer pruebas de carga con Jmeter, Nutch

(simulando robots de buscadores).

Drupalcamp Spain 2010

Monitoriza lo que pasa en tu
arquitectura de servidores

! Probar, probar y probar
! Monitoriza cada capa y punto crítico
! Identifica los puntos de ruptura