Drupal, Ubuntu, jQuery, CSS
Drupal
Drupal 7: Panels no me dejaba crear links dinamicos
0Bueno el titulo del post no se explica muy bien, pero que le voy a hacer, no tengo tanto espacio. Me explico:
Hice un panel con una url dinámica ”dashboard/!seccion“, y paralelamente cree un menú llamado “Secciones dashboard”
El problema se me dio cuando quise comenzar a agregar enlaces al menú del tipo ”dashboard/perfil“, ”dashboard/datos-de-la-cuenta“, etc. y me daba error al crear cualquier elemento:
Después de darle un poco de vueltas al asunto (google, foros, debug) termine dándome cuenta de la boludez que era, y es que para crear elementos de menú que apunten a un panel, primero tenes que darle permisos de acceso al panel (atento a la imagen porque no estoy hablando de permisos de Drupal):
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 7: ¿cómo agregar un menú en el área principal de administración?
0Hola. Hoy les muestro rápidamente como crear nuevas áreas en la zona de administración. A mí en particular se me hace especialmente útil para ciertos proyectos en los cuales tengo muchos módulos con muchas configuraciones y pantallas de administración. Al principio no estaba mal usar el área de administración de drupal, pero pronto mas que tarde se me hizo un quilombo (algo inmanejable) porque no solo estaban mis implementaciones propias, sino las de modulos de terceros.. En fin, que necesitaba un área propia en la que organizar mis cosas.
Sin más dilación, para definir un menú en el área de administración tenemos que definir un menú por medio del “hook_menu();” pero dotándolo de un par de cosas fuera de lo “normal”:
$items['admin/propio'] = array(
'title' => 'Propio',
'description' => 'Zona de implementaciones propias.',
//Primer cosa extra. esa funcion es la que recoje todas
//las definiciones para el area de administracion
'page callback' => 'system_admin_menu_block_page',
//No queremos que acceda todo el mundo, asi que lo
//restringimos a quien pueda acceder al area de administracion
'access arguments' => array('access administration pages'),
//system_admin_menu_block_page() es una funcion externa por
//lo que necesitamos decirle al menu donde está para poder usarla.
'file' => 'system.admin.inc',
'file path' => drupal_get_path('module', 'system'),
//Dashboard es el menu mas liviano dentro del core. le ganamos el lugar
'weight' => -16,
);
Lo anterior lo he puesto en un modulo de pruebas llamado “commons”, y quedaria asi:
/**
* Implements hook_menu().
*/
function commons_menu() {
$items['admin/propio'] = array(
'title' => 'Propio',
'description' => 'Zona de implementaciones propias.',
'page callback' => 'system_admin_menu_block_page',
'access arguments' => array('access administration pages'),
'file' => 'system.admin.inc',
'file path' => drupal_get_path('module', 'system'),
'weight' => -16,
);
return $items;
}
El resultado de lo anterior seria el siguiente:
Ya tenemos area de administración. vamos a poner algo dentro:
/**
* Implements hook_menu().
*/
function commons_menu() {
$items['admin/propio'] = array(
'title' => 'Propio',
'description' => 'Zona de implementaciones propias.',
'page callback' => 'system_admin_menu_block_page',
'access arguments' => array('access administration pages'),
'file' => 'system.admin.inc',
'file path' => drupal_get_path('module', 'system'),
'weight' => -16,
);
$items['admin/propio/prueba'] = array(
'title' => 'Prueba',
'description' => 'Esta es una prueba de<br /> la definicion de menues internos para <b>admin/propio</b>',
'page callback' => 'prueba',
'access arguments' => array('access administration pages'),
);
return $items;
}
function prueba() {
return "La vida es bella!";
}
Genial, ya tenemos algo dentro. No es de lo más útil pero dado este ejemplo ya sabrán ustedes que poner en lugar de un comentario tonto XD
El resultado es el siguiente:
PD antes que me pregunten porque no se ve reflejado en Drupal. BORREN EL CACHE (en admin/config/development/performance).
Listo, que lo disfruten.