Posted by nestor.mata on September 7, 2011 at 11:51am
Buenas,
Vamos a iniciar una discucion sobre como optimizar Drupal, consultas son aceptadas y todo tipo de discucion.
Saludos,
Nestor
Formas de optimizar drupal
Buenas,
Vamos a iniciar una discucion sobre como optimizar Drupal, consultas son aceptadas y todo tipo de discucion.
Saludos,
Nestor
Comments
Que temas tocar aqui
Buenas,
El hecho es que estoy pensando dar una charla en la proxima drupaleada sobre como optimizar Drupal y me gustaria abrir a discusion las diferentes formas de optimizar Drupal para saber en donde esta el mayor interes para armar la charla en cuanto a lo que mas interesada este la gente.
Primero, a grandes razgos hay varias formas de optimizar Drupal y lo recomendable es utilizar varias de estas para un resultado optimo, pero no solo se trata de optimizar por optimizar, sino encontrar cuales optimizaciones son las que lograrian mayor beneficio para cada caso, por eso mi intencion tambien es discutir en cuales situaciones se debe utilizar cada metodo.
Primero, la razon de hacer optimizaciones en Drupal se debe a una razon muy simple, todo el poder de Drupal no viene de gratis, el que muchas cosas esten listas para ser utilizadas en core o usando modulos, y todo el esquema modular de Drupal tiene un costo en rendimiento, no es lo mismo hacer una pagina sencilla que haga poco y escribirla en pocas lineas de codigo, haciendo solo uno o 2 queries a la base de datos que tener todo un sistema complejo que debe cargar modulos, lenguajes, permisos, etc, donde para el despliegue de cualquier pagina sencilla implica abrir muchos archivos de codigo (decenas o mas bien cientos) y hacer decenas de queries a la base de datos.
Dentro de las variables a analizar para esto hay que considerar varios factores:
- La version de Drupal (dependiendo de la version (5, 6 o 7) hay limitaciones en cuanto a lo que se puede hacer o pasos extra que se deben tomar para hacer algo que en otra version es mas sencillo
- Los recursos del servidor, hay tecnicas que aunque dan gran resultados pueden requerir mayores recursos del servidor y si este no tiene los recursos necesarios la tecnica mas bien podria bajar el rendimiento.
- Cual es el uso publico del sitio y el uso de usuarios logueados en el sitio.
- A que esta enfocado el uso del sitio y las caracteristicas que se le agregan o activan al sitio.
- La cantidad de hits que recibe el sitio
Para optimizar hay varias formas de hacerlo y cada una con diferentes tecnicas para lograrlo.
- Reducir la cantidad de requests estaticos al servidor (reverse proxy, CDN, cache, etc)
- Reducir la cantidad de request (parciales o totales) dinamicos al servidor (precompiladores y cacheadores de codigo, caches totales o parciales, ajax, etc)
- Optimizar el servidor web (configuracion, benchmark)
- Optimizar el servidor de base de datos (configuracion, benchmark)
- Optimizar el codigo (Aqui hay varias tecnicas mas avanzadas, como creacion de modulos custom para alterar algunas funcionalidades o reemplazarlas y en casos extremos parches)
Y la idea de este foro sera discutir algunas de estas tecnicas, oigo sugerencias en cuanto a con cuales quieren iniciar a discutir.
Saludos,
Nestor
http://nestor.profesional.co.cr
Nestor Mata
http://nestor.profesional.co.cr/es
Sobre Varnish (reverse proxy)
Queria comentar un poco sobre varnish.
Recursos del servidor
El servidor web puede manejar una cantidad limitada de request simultaneos, ya sean dinamicos o estaticos. En el caso de Drupal un request dinamico es bastante costoso, un solo request necesita abrir muchos archivos de codigo, templates, crear muchas variables, abrir conexiones a base de datos y traer datos de las bases y mantener algunos en memoria u otros procesarlos, podriamos hablar facilmente de unos 30 megas de memoria en un request y bastante procesamiento.
A diferencia de los request estaticos en los cuales se suele solamente abrir un archivo y redireccionar estos datos al output, lo cual no se compara en cuanto a nivel de procesamiento y memoria, pero el detalles es que una instancia que maneja request no se suele crear y destruir con cada request porque esto tambien es costoso, por lo que se suelen reutilizar (es parte de la configuracion del server), esto hace que el mismo proceso que atiende un request dinamico sea el mismo que atiende un request estatico, por lo que en un servidor tenemos un limite fijo de procesos que podemos atender simultaneamente.
Requests estaticos y dinamicos
Ahora, porque debe importarnos los request estaticos? Para empezar, una pagina comunmente se compone de 1 request dinamico que entrega el HTML y unos 20-80 requests estaticos (css, js, imagenes).
Si lo vemos desde esa perspectiva, el servidor mantiene ocupados bastantes recursos en responder requests estaticos que no cambian usualmente o de usuario en usuario.
Secciones de los requests dinamicos
En algunas tecnologias se usa el termino Hot Spot (o punto caliente) para definir un segmento que tendria mucho impacto en ser mejorado, ya sea porque se ejecuta muy frecuentemente o porque es muy pesado.
En Drupal hay secciones en las paginas que son mas pesados que otros, y a veces estos no cambian en un lapso de tiempo o en una session.
Tambien hay paginas en las que lo unico que cambia de usuario a usuario es una pequeña seccion.
Si tomamos esto en cuenta nos podriamos ver beneficiados con ser selectivos a la hora de hacer cacheo, ya sea cacheando secciones especificas o cacheando todo menos una seccion.
Anonimos y Autenticados
En cuanto a las posibilidades de cacheo hay una gran diferencia entre usuarios anonimos y autenticados.
En el caso de usuarios autenticados, es normal que parte de la informacion desplegada cambie para cada usuario, desde cosas tan sencillas como el nombre del usuario en alguna parte de la pagina hasta el contenido completo y el tema.
Pero, en cuanto a usuarios anonimos es otra historia, los usuarios anonimos no se pueden distinguir (usualmente, aunque si podemos saber su geo localizacion, browser, OS, etc, pero eso es otra historia), por lo que usualmente se despliega el mismo contenido para todos los usuarios anonimos.
Varnish para liberar al servidor
Ok, teniendo los conceptos que hablamos hace un momento, vamos a ver donde entra varnish en el juego.
Con varnish se puede hacer cosas muy interesantes, pero ahorita hablaremos de lo siguiente:
- Cacheo por tipos de archivo
- Cacheo por rutas o patrones
- Cacheo de paginas a usuarios anonimos
- Cacheo de secciones de una pagina
- Cacheo de una pagina con excepcion en secciones
Al configurar un varnish en frente de un servidor web podemos liberar al servidor web de muchisimos requests, incluso, si es un sitio enfocado a usuarios anonimos (como un blog, sitio de noticias, sitio informativo, etc) hasta podriamos hacer que el servidor web no reciba casi requests y todos sean servidos por el varnish.
Perfectamente podemos hablar de reducir los requests de 1.000 en una hora a 5 o 20, y lo mejor de todo, es que podrian aumentar los requests en esa hora a 10.000 o 100.000 y no aumentar ni un request al servidor web, reduciendo tambien los requests a la base de datos y aumentando la velocidad de respuesta de 1 segundo por request a unos milisegundos.
Lo dejo hasta aqui por ahora, y luego voy a describir los detalles de cada caso.
Saludos,
Nestor Mata
http://nestor.profesional.co.cr/es
Cache de tipos de archivos, rutas y patrones en Varnish
Ya entrando un poco mas en detalle con Varnish.
Varnish
Varnish es un proxy que coloca entre el usuario y el (o los) servidor(es) web, siendo Varnish quien accesa el servidor web, manteniendo cache del contenido y manipulando los headers y tal vez también el contenido.
Varnish redirecciona el request ya sea hacia el cache interno, hacia un servidor web u otro servidor web.
Debido a que varnish esta hecho para pocas cosas es muy eficiente haciendo lo que hace y permite jugar muy eficientemente con los requests.
Por ejemplo puede balancear los requests, o redirigir diferentes requests a un servidor u otro dependiendo de algun header, de alguna ruta o de algun tipo de archivo, o incluso de si un servidor funciona bien o da errores, en cuyo caso inclusive puede mantenerse dando una respuesta del cache mientras el servidor no funciona.
Configuración de Varnish
No voy a entrar demasiado profundo en los detalles de la configuración, pero aquí esta la documentación https://www.varnish-cache.org/docs/trunk/index.html
La configuración de varnish se encuentra el el archivo .vcl que tiene varios metodos para cada evento del flujo del request (algo como los hooks de drupal) donde se puede configurar o redireccionar el flujo del request.
Tal vez del que mas hablaremos será vlc_recv, que se da cuando inicial el procesamiento del request, en este punto tenemos la información de los headers del browser y podemos tomar decisiones de que hacer con el request, como indicar que pase directo (pass) o sea que no se utilice del cache, o que se revise el cache para saber si esta ahi y usar la version del cache si es valida (lookup), además tambien podemos alterar o agregar headers, o indicar si se debe procesar con ESI (Edge Server Includes).
Por ejemplo, podemos indicar que no se haga cache de un url de pruebas basandonos en el request url, esto para poder hacer pruebas sin que nuestros requests sean cacheados durante desarrollo:
#bypass del demo siteif (req.url ~ "demo.mydomain.com") {
return (pass);
}
Podemos indicar que siempre que haga cache de algun tipo de archivo basandonos en que el tipo de request sea GET (no POST) y en el url, de esta manera nos aseguramos de no enviar requests al servidor web que son siempre los mismos requests y que podemos dejar que varnish los cachee y descargamos de estos requests al servidor web:
if (req.request == "GET" && req.url ~ ".(gif|jpg|jpeg|bmp|png|tiff|tif|ico|img|tga|wmf)$") {return (lookup);
}
Podemos crear un header de X-Forwarded-For:
if (req.http.x-forwarded-for) {set req.http.X-Forwarded-For =
req.http.X-Forwarded-For + “, ” + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
Podemos definir que no se haga cache para usuarios autenticados:
if (req.http.Authorization || req.http.Cookie) {/* Not cacheable by default */
return (pass);
}
También podriamos enviar ciertos requests a un servidor diferente, por ejemplo enviar obtener todas las imagenes de un servidor optimizado para requests estaticos:
backend www {
.host = "www.example.com";
.port = "80";
}
backend images {
.host = "images.example.com";
.port = "80";
}
sub vcl_recv {
if (req.request == "GET" && req.url ~ ".(gif|jpg|jpeg|bmp|png|tiff|tif|ico|img|tga|wmf)$") {
set req.backend = images;
return (lookup);
}
...
X-Forwarded-For
Cuando accesamos el servidor web a travez de un reverse proxy como varnish, la IP que llega al servidor es siempre la IP del reverse proxy, no la IP del usuario, y por lo tanto no podemos saber de cual IP viene el usuario, por eso se setea un header X-Forwarded-For que contenga la IP del usuario, y luego hay que ir a la configuracion de apache e indicar que la IP se busque de este header y lo mismo para Drupal.
En el archivo de configuración de apache suele haber algo asi:
# If you are behind a reverse proxy, you might want to change %h into %{X-Forwarded-For}iLogFormat "%v:%p %{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O" common
En el archivo de configuración del site de drupal hay que descomentar lo siguiente:
'reverse_proxy' => TRUE,'reverse_proxy_addresses' => array('10.176.87.35'), // La IP interna de su reverse proxy
Con esto Drupal sabra que debe reemplazar la IP por el valor del header.
Saludos,
Nestor Mata
http://nestor.profesional.co.cr/es
Gracias,
excelente explicación introductoria, espero poder saber más del tema.
Contenido de la charla disponible en linea
Buenas,
El contenido de la charla de ayer de rendimiento esta disponible en la siguiente dirección:
http://nestor.profesional.co.cr/es/book/como-optimizar-drupal-para-alto-...
Saludos,
Nestor Mata
http://nestor.profesional.co.cr/es
Saludos Nestor, uso Varnish y
Saludos Nestor, uso Varnish y realmente ayuda pero tengo un problema que surgió tras la instalación de este. Yo uso en mis sitios domain access con cambios en htaccess para redireccionar a los usuarios a mi edición mobil, m.misitio.com. El problema es que desde que uso Varnish, la mayoría de mis usuarios se van a m.misitio.com incluso si teclean desde una PC de escritorio o Desktop. Alguna ayuda al respecto?
Gracias