Drupal, Ubuntu, jQuery, CSS
Capy
(62 comments, 142 posts)
This user hasn't shared any profile information
Jabber/GTalk: capy.net@gmail.com
Posts by Capy
Instalar Solr y configurar multiples cores en Linux Ubuntu
0Aclaraciones:
- El proceso de instalación de Solr es valido para cualquier otra versión de Solr.
- Un core es un hilo nuevo dentro de la misma instancia de Solr. Esto permite que se corra una sola instancia de Solr pero con varios buscadores.
Este tutorial asume que tienen instalado Java 7 y tomcat 7. Si tienen las versiones 6 le cambian el numero donde sea oportuno y funciona.
Vamos a ello:
Cuando tengas en tus manos el paquete se Solr, descomprimelo y ponte con la consola dentro de esa carpeta.
Cambia a sudo:
sudo su
Curiosidad: Aunque en el paquete que descargamos de Apache Solr haya al rededor de 2950 archivos solo nos van a hacer falta al rededor de 10:
Lanzamos en consola lo siguiente:
cp dist/apache-solr-*.war /var/lib/tomcat7/webapps/solr.war mkdir /var/lib/tomcat7/solr cp -R example/multicore/core0/ /var/lib/tomcat7/solr/core0 mkdir /var/lib/tomcat7/solr/core0/data sudo chown -R tomcat7:tomcat7 /var/lib/tomcat7/solr/core0
Ahora edita /var/lib/tomcat7/solr/solr.xml, pega lo siguiente y guárdalo.
<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true" sharedLib="lib">
<cores adminPath="/admin/cores">
<core name="core0" instanceDir="core0">
<property name="dataDir" value="/var/lib/tomcat7/solr/core0/data" />
</core>
</cores>
</solr>
Edita /etc/tomcat7/Catalina/localhost/solr.xml, pega lo siguiente y guárdalo.
<?xml version="1.0" encoding="UTF-8" ?> <Context docBase="/var/lib/tomcat7/webapps/solr.war" debug="0" privileged="true" allowLinking="true" crossContext="true"> <Environment name="solr/home" type="java.lang.String" value="/var/lib/tomcat7/solr" override="true" /> </Context>
Listo, reiniciemos tomcat para ver en funcionamiento el core que hemos creado:
service tomcat7 restart
Entramos en http://localhost:8080/solr/ y lo vamos a ver.
——————————————————————————————————————————-
Bueno ya tenemos un Solr con un core, pero tiene poco sentido montar un Solr de multicores que tenga un solo core, así que vamos a crear uno mas.
Para este nuevo core (y todos los que quieras crear) hay que hacer dos cosas:
1: copiar la carpeta core0 junto a su owner para ahorrarnos de andar creando la misma estructura:
cp -Rp /var/lib/tomcat7/solr/core0 /var/lib/tomcat7/solr/paraDrupall
NOTA: No olvides editar /var/lib/tomcat7/solr/paraDrupal/conf/schema.xml y /var/lib/tomcat7/solr/paraDrupal/conf/solrconfig.xml para ajustar sus parámetros.
2: actualizar /var/lib/tomcat7/solr/solr.xml agregandole un nuevo tag con lo siguiente:
<core name="paraDrupal" instanceDir="paraDrupal"> <property name="dataDir" value="/var/lib/tomcat7/solr/paraDrupal/data" /> </core>
Reinicia tomcat y ya tenes otro core.
Suerte y saludos.
Copiar y pegar en Putty en Linux
04 weeks ago
Me lo tengo merecido por usar Windows.
Para los que estén usando putty sobre Linux puede que hayan notado que las siguientes funcionalidades no están disponibles:
- Cuando seleccionas algo en putty esto automáticamente queda copiado por lo que podes ir a notepad (por decir algo) y pegarlo directamente.
- Cuando tenes algo copiado de notepad y lo quieres pegar en putty solamente haces click derecho sobre el y se pega.
Bueno, a priori me parecía que no existía esa funcionalidad y no le di mayor importancia hasta que un dia di con esa funcionalidad por casualidad.
Resulta que cuando seleccionas algo en putty esto si que se copia a un portapapeles, pero la forma de pegar ese texto copiado es con el click central (la rueda del ratón). Esto es para ambos sentidos. Si seleccionas algo de gedit (por decir algo) y haces click central en putty, también se va a pegar el texto.
Ya sabes lo que se dice. Nunca te acostaras sin haber aprendido algo nuevo.
Saludos.
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!.