Performance en Drupal 7

Fernando Paredes

Karim Boudjema

 1. Importancia del rendimiento (Fer)
 2. Rendimiento - Escalabilidad (K)
 3. Caching (Fer)
 4. Tipos de memoria caché: Servidor Web, PHP, Drupal y Base
de datos (K)
 6. Testing JM Meter - XHProf- AB - Devel (K)
 7. Optimizar el código PHP (APC+buenas praticas) (Fer)
 8. Core Cache De Drupal (tablas + configuración) (K)
 9. APC, Memcache, File (Fer)
 10. Boost (K)
 11. Demo y Conclusiones (K)

Karim Boudjema (KarimB)

Drupal themer and developer

Con Drupal desde 2008

Miembro activo de Drupal
Bolivia y Drupal Belgium

Especialidades: Text Mining
(NLP), Periódicos online

Drupal Blog:

http://www.webenstock.com

Trabajo

Technical Leader
@develCuy Comunidad
Facebook, Twitter, Identi.ca Fundador de Drupal Perú

http://develcuy.com http://drupal.org/user/125473

1. Afecta la experiencia del usuario

1. SEO, los buscadores han comenzado a
despriorizar las páginas web lentas

2. La arquitectura puede verse muy afectada
con tal de conseguir mejor rendimiento.

No importa cuan asombrosa sea una página
web, si es lenta entonces el usuario
insatisfecho ni alcanzará a verla o nunca más
volverá, incluido el usuario “indexador web”.

El desafío és proveer contenidos, formatos y
funcionalidades sin afectar el rendimiento.

El rendmiento está dirigido por la
arquitectura (architecture driven)

 Escalabilidad
◦ El sistema puede acomodarse al incremento de
 su uso
 su volumen de datos
 Rendimiento
◦ Tiempo de respuesta del servidor + tiempo de
carga de la página
 „Que tan rápido se carga la página?‟

Del Top 50 de los sitios de AL, todos

los sitios toman menos del 14% del

tiempo de carga total, para obtener el

documento HTML.

El 86% restante es para obtener los

documentos vinculados al documento

HTML como CSS, JS, imágenes.

Una clave de la performance se

encuentra en la optimización del

Front End.

elcomercio.pe - HTML = 622ms (3%) – Documents: 19852 ms

datos duplicados de otros
"Es un conjunto de
originales, con la propiedad de que los datos
originales son costosos de acceder,
normalmente en tiempo, respecto a la copia en la caché.
Cuando se accede por primera vez a un dato, se hace
una copia en el caché; los accesos siguientes se
realizan a dicha copia, haciendo que el tiempo de
acceso [...] al dato sea menor."
- Wikipedia

Caché
vacía

Caché
llena

SQL
APACHE PHP Queries MySQL

Browser Reverse MOD OpCode Cache Query
Cache CDN Expires Boost
proxy Deflate
Cache engine Cache

LINUX

 No podemos implementar políticas de
rendimiento sin una evaluación.

 Apache Bench (AB)
 Devel
 Jmeter
 XHProf (Ahora integrado a devel)
 On line tools:
◦ Load Storm: http://loadstorm.com/
◦ Monitis: http://portal.monitis.com/

Here comes your footer  Page 16

◦ Fácil, simple y todos lo tenemos instalado

◦ ab -c 1 -n 100 http://example.dev/
◦ ab -c 1 -n 100 –C PHPSESSID=<sessid> http://example.dev/

◦ Donde
 -c = concurrencia de los requerimientos
 -n = total de requerimientos a la pagina
◦ En este caso haremos 100 requermientos a la página
http://example.dev/

◦ Un solo indicador: „Requests per second‟

◦ Evaluaremos nuestras distintas políticas de caché con este
indicador

 Permite evaluar para una página:
◦ Mysql
 # total de consultas
 Tiempos total para todas las consultas en ms
 Ver las consultas más lentas
 Para cada consulta
 Tiempo de realización en ms
 # de veces que la consulta ha sido realizada
 Ver EXPLAIN
◦ Página
 Tiempo total de carga de la página en ms
◦ Hacer la diferencia entre la performance de Mysql y del resto de la página
◦ Uso de la Memoria
 Para configurar
◦ Configuation >Development > Devel Settings

 Performance Logging
◦ Ya no es parte del módulo devel desde 07/2011
◦ Será parte del módulo Performance:
http://drupal.org/project/performance
◦ Podemos utilizar Profiling
 http://drupal.org/project/profiling

“¿Éslo que la gente usualmente
considera la forma apropiada de hacer algo?
¿Hay una forma "usual", es decir, una
forma generalmente aceptada? ¿Se
endiente como la forma “apropiada”? Si
podemos responder esto afirmativamente,
entonces tenemos una Buena Práctica.” (traducido)
- The IT Skeptic

En el código fuente de Drupal, la caché se
guarda en dos lugares diferentes:
- La memoria estática de PHP
- La caché de Drupal

<?php
function phpmemory_set() {
 static $value;
 if (!isset($value)) {
 $value = "gran cantidad de datos";
 }
 return $value;
 }

?>

<?php
function drupalmemory_set() {
 $cache = cache_get('value');
 if (empty($cache->data)) {
 cache_set($value, 'value');
 }
 else {
 $value = $cache->data;
 }
 return $value;
 }

?>

<?php
static $value;
 if (!isset($value)) {
 $cache = cache_get('value');
 if (empty($cache->data)) {
 cache_set($value, 'value');
 }
 else {
 $value = $cache->data;
 }
 }
 return $value;
?>

 Evita múltiples consultas a la base de datos

 Sirve sobre todo para los usuarios anónimos

 Conocer cada tabla nos permitirá elegir los bins con los
distintos cache engine (memcache, file, apc)

 Nos permite ganar 500% a 700% de performance para
usuarios no autenticados

 En D7 tenemos nuevas tablas

 El sistema de caché de Drupal almacena sus datos en las
siguientes tablas de la base de datos:
Por defecto Configurable

1. cache – Conf. de los modules, schemas, themes ect. 1. cache_page – registra una copia
2. cache_bootstrap – variables y información durante el completa de del código html de las
bootstrap paginas pero solo para usuarios no
3. cache_field – fields de las entidades autenticados.
4. cache_images – imágenes procesadas 2. cache_block – registra una copia de
5. cache_path – URL alias los bloques
6. cache_menu – registra una copia de los menús y de las
URLs asociadas a estos menús
7. cache_filter – registra una copia del contenido de
nuestros nodos filtrados
8. cache_form – registra una copia de los formularios del
sitio
9. cache_update – registra los updates disponibles

 Vamos en Configuration > Development > Performance
 Caché de páginas
◦ Mínimo de permanencia en cache de Drupal
◦ Máximo de permanencia en cache externo
◦ Compresión de páginas: siempre mejor con Apache
 Para ver si nuestro server ya realiza la compresión:
http://www.whatsmyip.org/http_compression/

 Caché de bloques
◦ No lo necesitamos para usuarios no autenticados

 Optimizaciones del ancho de banda
◦ Optimizar archivos CSS: Activado (solo en producción)
◦ Optimizar archivos JavaScript: Activado (solo en prod.)

http://drupal.org/project/apc

PHP PHP
256mb 256mb

APC APC
64MB 64MB

http://drupal.org/project/memcache
Memcache
PHP
server
256mb
64MB

Memcache
PHP
server
256mb
64MB}

http://drupal.org/project/filecache

PHP Filesystem
256mb 1 GB

PHP Filesystem
256mb 1 GB

Memcache
PHP Filesystem
server
256mb 1 GB
APC 64MB
64MB

Memcache
PHP Filesystem
server
256mb 1 GB
APC 64MB
64MB

•Boost crea un archivo .html para
todas las páginas visitadas por los
usuarios anónimos.

•El próximo usuario anónimo leerá
este archivo .html en vez de ir al
index.php y la BD.

•Es un excelente caché por
archivos estáticos que se ejecuta
desde el .htaccess gracias a
mod_rewrite.

 Pensar en performance desde el principio
 Performance es un diseño ligero
 Pocos módulos (process)
 APC Opcode
 Consultas Mysql optimizadas (Explain) y Query Cache
 Robot.txt (Crawl-Delay: 10)
 Usuarios anónimos
◦ Cache del core (solo páginas)
◦ Boost
◦ Varnish
◦ Cache actions (mantenimiento)
 Usuarios autenticados
◦ Cache engine APC para Bins importantes y con mucha actualización
◦ Cache engine memcache si cantidad grande de datos
◦ Cache file si no cambia mucho en el tiempo
Testing, testing, testing…

Performance en Drupal 7

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Performance en Drupal 7

Semelhante a Performance en Drupal 7 (20)

Último

Último (11)

Performance en Drupal 7