Drupal, Ubuntu, jQuery, CSS
Drupal 6
Benchmark Drupal 7 + APC + Memcached + Varnish sobre usuarios anónimos
0Vamos a hacer algunos testeos para ver lo que podemos llegar a ganar en performance al implementar una serie de tecnologías sobre Drupal 7.
Las pruebas las realizare sobre una instalación LAMP estándar de Ubuntu (Linux Mint en realidad):
- mysql 5.1.58 (Con su configuración por defecto)
- php 5.3.6 (Con su configuración por defecto)
El software para mejorar la performance que usé y las versiones de cada uno son:
- APC-3.1.9
- memcached 1.4.7
- Varnish 3.0.4
Esta prueba es solo para que nos demos una idea de lo que podría llegar a implicar el aplicar estas tecnologías en nuestro sitio de Drupal 7, por lo que he dejado fuera cualquier explicación técnica.
Las pruebas las hice en un core2Duo @ 2.2ghz de 2 núcleos en un Linux Mint de 64bits y 8gb de ram.
La idea es ir agregando tecnologías e ir viendo el teórico beneficio que esta aporta aplicadas a la practica.
Lo primero es lo primero. vamos a hacer un bench de Drupal 7.10 en sobre nuestro LAMP sin haber tocado su configuración inicial.
Utilice Apache benchmark (ab) para todos los testeos variando la concurrencia y cantidad de request para aprovechar al máximo los recursos de los que disponía en cada testeo que hice.
Primera ronda. Estableciendo un punto de referencia.
Test 1: Drupal 7 sin cache de ningún tipo.
Resultados:
Requests per second: 5.71 [#/sec] (mean)
Transfer rate: 45.35 [Kbytes/sec] received
Test 2: Drupal 7 marcandole las opciones “Aggregate and compress CSS files.” y “Aggregate JavaScript files.” en “admin/config/development/performance”
Resultados:
Requests per second: 6.38 [#/sec] (mean)
Transfer rate: 46.27 [Kbytes/sec] received
Podemos apreciar que no hay cambios. nada que comentar.
Test 3: La configuración del testeo anterior + “Cache blocks” en “admin/config/development/performance”
Resultados:
Requests per second: 5.18 [#/sec] (mean)
Transfer rate: 37.54 [Kbytes/sec] received
Pasados los tes primeros test ya no quedan dudas que el cuello de botella de los procesadores son los limitantes. Apenas si pudimos conseguir que varíe el resultado.
——————————————————————
Hasta acá fue lo aburrido, porque en realidad lo anterior no tiene ninguna magia, pero nos da una buena idea de desde que base estamos partiendo. Nuestro objetivo es subir grotescamente la media de request por segundo partiendo de los aproximadamente 6 que hemos conseguido hasta ahora.
Test 4: La configuración del test anterior + “Cache pages for anonymous users” (El cache normal de Drupal).
Resultados:
Requests per second: 127.22 [#/sec] (mean)
Transfer rate: 921.83 [Kbytes/sec] received
Bueno bueno bueno, esto ya es otra cosa. El cache de Drupal por si solo incrementa los request de una forma brutal, pero no nos quedamos ahí ni en broma, vamos a por mas RPS (request por segundo)
——————————————————————
Segunda ronda. tecnologías y configuraciones foráneas:
Test 5: La configuración del test anterior + APC.
Este es uno de los cambios mas recomendados siempre que queramos obtener un incremento de performance (y mejor aprovechamiento de la ram disponible) sin tener que tocar ni una sola linea de código de nuestro Drupal.
Resultados:
Requests per second: 440.43 [#/sec] (mean)
Transfer rate: 3191.39 [Kbytes/sec] received
Boom! performance X4!. Vamos por buen camino. Agreguemos mas de esas cosas que recomiendan los que saben…
Test 6: La configuración del test anterior + Memcached
Para esta prueba instalé el modulo memcache (http://drupal.org/project/memcache) en su versión 7.x-1.0-rc2 y lo configuré en su forma mas básica según las instrucciones de su configuración.
Resultados:
Requests per second: 397.38 [#/sec] (mean)
Transfer rate: 2734.53 [Kbytes/sec] received
No hemos visto mejora alguna pero no porque Memcache no sirva, al contrario, en futuros bench les voy a mostrar como si que ayuda, pero bajo este entorno poco sirve ya que es una capa intermedia con la DB y estamos usando el cache de Drupal que apenas si la toca… en fin, en el próximo bench les muestro, paciencia.
Hasta ahora hemos conseguido mejorar los iniciales 6 RPS del principio por fabulosos 400 RPS de media, pero aun nos queda un paso mas para mejorar los request para usuarios anónimos, y ese es Varnish
Test 7: La configuración del test anterior + Varnish
Resultados:
Requests per second: 6166.57 [#/sec] (mean)
Transfer rate: 45075.00 [Kbytes/sec] received
Acaso hay algo que añadir?
Conclusiones:
Hemos visto como Drupal 7 sin ningún tipo de cache activo es una muy mala idea a la hora de ponerlo en producción.
El cache que trae de serie no es opcional, sino que es mandatorio. No activar como mínimo esta capa de cache en Drupal derivaría automáticamente en un uso elevadisimo de los recursos disponibles, esto acompañado de tiempos de entrega mucho mas largos y por consiguiente la insatisfacción de nuestros clientes.
APC es una excelente adición a nuestro servidor en general ya que agiliza el procesamiento de cualquier pagina escrita en PHP y particularmente en Drupal es un beneficio directo tanto para usuarios anónimos como para usuarios logueados. Recomiendo su uso sin dudarlo aunque hay que hacerlo con cabeza, documentación y alguien que sepa lo que hace si no quieren volver inestable vuestro sistema.
Memcache es una herramienta que no puede faltar en un buen servidor y es harto eficiente para usuarios no logueados en el terreno de Drupal, pero en una instalación en la que casi todos los visitantes sean anónimos, apenas van a sentir la mejora.
Por ultimo y el mas importante, Varnish, que demostró el salto ABISMAL que puede llegar a proporcionar en velocidad cuando lo ponemos a trabajar con una instalación de Drupal. Sin duda pues, esta es la herramienta mas potente de las que hemos utilizado en este bench, pero a su vez, la mas complicada de configurar.
Resumiendo la mejor combinación para usuarios anónimos:
Cache de Drupal = performance decente / Configuración… bueno no lleva configuracion XD. (ganancia de 21x con con respecto a los 6 de media iniciales)
Cache de Drupal + APC = Muy buena performance / Configuración media. (ganancia de 73x con con respecto a los 6 de media iniciales)
Cache de Drupal + APC + Varnish = Bruta performance / Configuración avanzada. (ganancia de 1027x con con respecto a los 6 de media iniciales)
Disclaimer:
No son ni de lejos las mejores versiones ni servidores los que he usado, pero procuré enfocarme en estos debido a que son los mas extendidos/populares en nuestro creciente mundo llamado Drupal.
Saludos.
Drupal: El “view” de un cck no está disponible cuando hago node_load() [Solución]
1Cuando cargamos un nodo con node_load(), si quisiéramos hacer uso de la propiedad “view” de un campo CCK veríamos que la misma no existe:
$node = node_load(999);
var_dump($node->field_precio[0]);
array(2) {
["amount"]=>
string(6) "100.00"
["currency"]=>
string(3) "EUR"
}
Esto pasa porque CCK solo prepara esta propiedad cuando un nodo se esta por imprimir mediante node_view(). Si lo que necesitas es usar node_load() en lugar de node_view() la solución es inyectarle la propiedad “view” mediante la función que el mismo modulo de CCK utiliza:
$node = node_load(999);
$node->field_precio[0]['view'] = content_format("field_precio", $node->field_precio[0]);
var_dump($node->field_precio[0]);
array(3) {
["amount"]=>
string(6) "100.00"
["currency"]=>
string(3) "EUR"
["view"]=>
string(11) "100.00 EUR"
}
bye!.
Drupal 6: db_last_insert_id() no funciona correctamente [Solución]
08 months ago
Es curioso como un error de este tipo se les llega a escapar y entra en producción.
¿Por qué no funciona? porque a algun iluminado se le ocurrio que solo lanzando la query ‘SELECT LAST_INSERT_ID()’ sin especificar la tabla sobre la que se quiere obtener el ultimo registro insertado Drupal iba automagicamente a obtenerlo…. ERROR. Ah y por cierto incluso la query ’SELECT LAST_INSERT_ID()’ bien armada también suele fallar.
/**
* Returns the last insert id.
*
* @param $table
* The name of the table you inserted into.
* @param $field
* The name of the autoincrement field.
*/
function db_last_insert_id($table, $field){
return db_result(db_query('SELECT LAST_INSERT_ID()'));
}
La función que soluciona este problema es esta:
/**
* Version modificada del analogo de drupal que soluciona un problema comentado en foros.
*
* @param string $table tabla sobre la que se quiere obtener el ultimo id insertado
* @param string $field cual es la columna que tiene el id
* @return int
*/
function custom_db_last_insert_id($table, $field) {
$result = db_query("SELECT $field FROM {$table} ORDER BY $field DESC LIMIT 1");
$row = db_fetch_object($result);
return $row->$field;
}
Solo resta agregar que uso esta solución hace mas de un año y funciona bien.
Drupal: Error “HTTP request status”
0Si ves que drupal te dice en el reporte de estado (admin/reports/status) algo como esto:
Your system or network configuration does not allow Drupal to access web pages, resulting in reduced functionality. This could be due to your webserver configuration or PHP settings, and should be resolved in order to download information about available updates, fetch aggregator feeds, sign in via OpenID, or use other network-dependent services.
Podes decirle a Drupal que ignore este error poniendo la siguiente linea al final del archivo settings.php:
$conf['drupal_http_request_fails'] = FALSE;
Al que le interese profundizar mas en el asunto aca esta el hilo:
PD: lo estoy ignorando al error porque en mi servidor si hay comunicación y aunque Drupal me dice que no la hay, el mismo es capaz de avisarme cuando hay actualizaciones… curioso.