Actualizado para incluir la instalación de APC (Alternative PHP Caché) y optimizar también la parte PHP de Magento.

Entre los usuarios de software de comercio electrónico (e-commerce) es de sobra conocida la edición Community de Magento. Lo tiene todo: es potente, modulable, versátil, estéticamente buena, gratis y de código abierto. Pero como todo en esta vida, tiene un gran pero: es bastante más lento que otros sistemas como el cuasi-difunto osCommerce, Zen Cart y similares. La explicación es sencilla: Magento NO es competencia de este tipo de software de carta de compras, sino de software empresarial de miles de euros que corren en servidores igual de caros.

En mi caso concreto, tengo en inminente estado de producción un servidor dedicado de bajo coste (con Intel Atom) y he mejorado muchísimo el rendimiento general de Magento “simplemente” ampliando el tamaño de la caché de MySQL. Aquí os dejo lo que hice:

Activando y ampliando la caché de MySQL

Primero comprobamos si la caché para consultas está habilitada en nuestra instalación de MySQL, ejecutando esta consulta (desde phpMyAdmin también vale):

SHOW VARIABLES LIKE 'have_query_cache';

Que devolverá YES si está correctamente activado.

mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name | Value    |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+

Después comprobamos el tamaño asignado a la caché para queries . Si lo tenemos a cero, entonces está desactivado aunque en el paso anterior se obtuviésemos YES. Ejecutamos:

SHOW VARIABLES LIKE 'query_cache_size';

Y obtendremos el tamaño asignado en Bytes (por defecto creo que suele estar en 16777216 Bytes = 16 MB):

mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+----------+
| Variable_name | Value       |
+------------------+----------+
| query_cache_size | 16777216 |
+------------------+----------+
1 row in set (0.00 sec)

En mi caso 16MB de RAM se quedaban escasos y amplié el tamaño a 32MB. Dependiendo del uso, del hardware y de la cantidad de RAM instalada, quizá para muchos sea más conveniente ampliarlo hasta 64MB. No he probado cantidades mayores, pero se comenta que tampoco es conveniente poner más de esta cantidad.

Finalmente, para cambiar el tamaño sólo tenemos que editar el archivo mysql.cnf. En mi máquina Ubuntu está en /etc/mysql/my.cnf y lo edité mediante SSH con nano sin problemas. Debajo de la sección [mysqld] cambiamos:

query_cache_size=32M

Y reiniciamos MySQL (mysqld), aunque en mi caso parece que cogió las nuevas opciones sin necesidad de reiniciar, el cambio fue instantáneo. Y la mejora, también :jeje:

Instalación de APC para mejorar el rendimiento de PHP

APC es una extensión para PHP que mejora el sistema de caché de este lenguaje almacenando el código intermedio (“opcode”) sin tener que realizar modificaciones a nuestro código (en este caso, el de Magento). Todo funciona de forma transparente para el usuario y la propio aplicación, aunque en el caso de Magento tendremos que “avisarle” de que puede utilizar este sistema como veremos más adelante.

Al igual que para la optimización de MySQL, necesitaremos privilegios de administrador en nuestra máquina y acceso shell (recomiendo SSH) para instalar los paquetes necesarios. APC está disponible en casi todas las distribuciones Linux, pero los pasos a continuación sólo se aplican si utilizas una distro basada en Debian, como por ejemplo Ubuntu (8.04 Hardy en mi caso).

Primero actualizamos los paquetes de las fuentes:

sudo apt-get update

Instalamos los paquetes necesarios (nota: tanto php5-dev como apache2-threaded-dev son únicamente herramientas de desarrollo, no cambiarán ni arruinarán nuestra instalación actual de PHP5 ni Apache):

sudo apt-get install php5-dev php-pear apache2-threaded-dev

Si nos hace esta pregunta, simplemente pulsamos ENTER:

 1. Use apxs to set compile flags (if using APC with Apache)? : yes
1-1, 'all', 'abort', or Enter to continue: 

Y por último compilamos el módulo APC ejecutando:

sudo pecl install apc

Ahora incluiremos el módulo apc.so recién compilado en nuestra configuración de PHP, añadiendo las siguientes líneas al final de nuestro archivo php.ini (en mi caso en /etc/php5/apache2/php.ini), guardamos y reiniciamos el servidor Apache:

extension=apc.so

[APC]
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 64
apc.max_file_size = 10M
apc.stat=1

Y para terminar del todo, el paso final: hacer que Magento utilice APC, para lo que editaremos el archivo de configuración local situado en app/etc/local.xml de nuestra instalación de Magento, entre los tags (aconsejo ponerlo al final de la sección global, una línea más abajo de ):

    apc
alphanumeric

Resultados

Con esto, deberíamos tener:

• La propia caché de Magento activada en Options » Caché Management
• La caché de consultas de MySQL activada y con un límite más amplio
• Y el módulo APC cacheando el código intermedio de PHP

En mi servidor dedicado con Intel Atom, el tiempo de espera se ha reducido en cerca de un 40% al optimizar MySQL y posteriormente un 38% adicional al incluir APC. No tengo datos concretos de cuando active la caché interna de Magento, pero desde luego la diferencia fue mucho menor que cuando activé cada uno de estos sistemas por separado. Ahora sí, podemos decir que Magento ha llegado para quedarse sin miedo a hablar de rendimiento o lentitud para nuestros clientes.

Con la salida de la versión final del iPhone OS 3.0, muchos desarrolladores se han encontrado con que ya no es posible parchear el framework MobileInstallation tal como se venía haciendo con las versiones 2.x para poder probar sus propias aplicaciones antes de pagar los $99 por la cuenta de editor en el App Store.

Disclaimer: El objetivo de esta guía es permitir la carga de aplicaciones sin DRM en el nuevo software 3.0 del iPhone/iPod Touch con fines de desarrollo/educativos. En ningún momento resolveré dudas o consultas sobre cargar aplicaciones protegidas con copyright procedentes de la App Store, puesto que además es ilegal en muchos países.

Aquellos que han accedido al directorio de rigor en esta nueva versión habrán descubierto que Apple ha modificado el sistema de autorización que antes era controlado por MobileInstallation por un nuevo sistema contenido en /lib/exec/installd, por lo que todos los desbloqueos basados en el anterior sistema (básicamente todos los miPatch que han ido saliendo en Cydia) no tienen efecto y pueden provocar bloqueos al inicio, teniendo que poner el dispositivo en modo DFU para restaurarlo.

Afortunadamente, los chicos de Hackulous han creado un nuevo parche especialmente diseñado para installd y fácilmente instalable desde Cydia, siempre y cuando hayamos realizado el Jailbreak correspondiente. Estos son los pasos:

• Abre Cydia en tu 3.0 con el jailbreak aplicado (Icy da problemas).
• Añade la fuente http://cydia.hackulo.us
• Instala la aplicación AppSync, dentro de la categoría Hackulous
• Reinicia el iPhone para evitar problemas y cuelgues (imprescindible)
• Proceder con iTunes como siempre, arrastrando los ficheros .IPA que hemos empaquetado desde Xcode
• Sincronizar y listo

No me cuentes historias, show me the code!

Obtener los archivos adjuntos a una entrada

Buscando por el Codex de WordPress encontré algo que podía ser útil: la función get_children(). Por lo visto WordPress relaciona internamente cada fichero con su entrada correspondiente, y esta función devuelve todos los adjuntos que hemos subido mediante el uploader al escribir la entrada. Además permite filtrar el resultado por tipo (attachment), el identificador de la entrada (post_id) y el tipo MIME del archivo (image).

$attachments =& get_children( array(
	'post_type' => 'attachment',
	'post_parent' => get_the_ID(),
        'post_mime_type' => 'image'
));

Tras varias pruebas -no todo sale siempre a la primera- compruebo que las todas miniaturas funcionan sin tener que usar los campos personalizados (que sinceramente, nunca me iba a molestar en rellenar) y me voy a la cama tan tranquilo.

El desastre

Al día siguiente… ¡horror!, el blog carga lentísimo y pocos minutos después recibo un mensaje del Hostmaster porque hay un proceso que está llamando continuamente a una IP caída (que resultó ser la de Twitter). Desactivo el plugin culpable -Twittwoo- e instalo WP-Super-Cache a petición del Hostmaster. Segundo horror: las miniaturas a tomar por saco. Borro la caché que había generado, desactivo y elimino todos los ficheros. Siguen sin aparecer las miniaturas y el Hostmaster me indica que desde el día de año nuevo a las 21:15h aparece este otro mensaje de error en los logs del servidor:

[Thu Jan 01 21:15:04 2009] [error] [client 84.77.X.X] Usage: file [-bcikLhnNsvz] [-f namefile] [-F separator] [-m magicfiles] file..., referer: http://www.frickr.es/
[Thu Jan 01 21:15:04 2009] [error] [client 84.77.X.X]        file -C -m magicfiles, referer: http://www.frickr.es/

Pues parece que timthumb.php hace una llamada a una función que calcula no-se-qué de un número mágico y falla o el servidor no la soporta. Y encima el WP-Super-Cache me ha modificado el .htaccess, pero por suerte el Hostmaster me sube uno limpio para WordPress. Resumiendo: que el dichoso timthumb.php en realidad nunca ha funcionado bien, y hay que encontrar otra solución.

Me pongo a buscar otra vez en el Codex y esta vez descubro que desde la versión 2.5 WordPress permite especificar tamaños para generar miniaturas de todas las imágenes que se suben. Perfecto: si nativamente el sistema genera las miniaturas, y yo puedo acceder a todos los adjuntos de un post, me falta relacionar el adjunto con la miniatura del tamaño que necesito. Sigo inspeccionando las funciones internas y me encuentro con wp_get_attachment_image_src(), justo lo que necesito:

(array) $image = function wp_get_attachment_image_src (
     $attachment_id,
     $size='thumbnail',
     $icon = false
);

// Returns an array containing:
$image[0] => url
$image[1] => width
$image[2] => height

Bueno, pues vamos a configurar WordPress y a modificar el código del tema (theme) para hacer que soporte las miniaturas internas de WordPress y eliminar cualquier rastro del timthumb.php.

Página 2 » Insertando el código final en el theme

Cuando estás realizando una web adaptada a dispositivos móviles, hay que favorecer el uso de técnicas CSS avanzadas (los navegadores basados en WebKit se prestan más a ello) pero siempre necesitas algunas imágenes con logos, iconos, botones… La mejor técnica siempre es utilizar la “presentación preliminar de imagen” de Fireworks o Photoshop para reducir al máximo la paleta de colores en archivos GIF o PNG.

Otro escenario típico es en el que tenemos una imagen enorme (de más de 1.000 px de ancho) que queremos usar como fondo (background), como por ejemplo en nuestra página de Twitter, pero pesa demasiado y tarda mucho en cargar. También pueden ser fotos con muchos colores en las que no podemos reducir la paleta sin una pérdida muy aparente de la calidad, pero necesitamos reducirlas como sea.

Para todos estos casos, Stoyan Stefanov y Nicole Sullivan, del equipo de Rendimiento Excepcional (Exceptional Performance team) de Yahoo! han creado smush.it!, un proyecto open source de optimización de imagenes online que reúne varias herramientas de procesamiento tales como ImageMagick, pngcrush, optipng, pngrewrite, jpegtran y gifsicle, con las que realiza varios patrones y nos devuelve automáticamente aquella con menor tamaño (generalmente un PNG). Además conserva los metadatos EXIF y de geolocalización de nuestras fotos.

Como cabe esperar, la aplicación es muy rápida y proveen una API gratuita para enviar y recibir desde nuestros scripts mediante simples llamadas GET y respuestas JSON (ideal para AJAX).