Únete a la Comunidad Magento

Regístrate gratis para publicar preguntas y recibir un resumen semanal con lo mejor de la comunidad
REGISTRO GRATIS

Optimización de rendimiento para Magento (1 y 2)

Tema en 'Soporte General' iniciado por factoriadigital, 6/3/18.

  1. factoriadigital

    factoriadigital Administrator Miembro del equipo

    68
    0
    6
    Hola a todos, hace poco desde FactoriaDigital dimos una charla sobre optimización de rendimiento en Magento para Magetitans Mexico 2018, el evento de referencia sobre Magento en México y America Latina, sin más preambulos ahi os la dejo:

    Propósito
    Cubrir las configuraciones y optimizaciones más habituales y efectivas, de cara a obtener el máximo rendimiento con el menor esfuerzo posible. Para ello vamos a evitar las optimizaciones inefectivas o incluso perjudiciales, como por ejemplo puede ser tener Redis en una instalación con un único servidor para todo.

    Vamos a empezar de más sencillo, a más complejo. Espero que sea de vuestro interés.

    Unir ficheros CSS y Javascripts

    [​IMG]

    Esta es una opción interesante que debería estar siempre habilitada. Debe ser testada siempre ya que a veces puede causar problemas con algunas extensiones o scripts. Esta opción unifica en un único fichero todos los ficheros CSS y Javascript que use nuestra página web y así el cliente solo realiza una única descarga del fichero.

    Con esto usaremos un único thread del servidor web para descargar varios ficheros, consiguiendo así que la web cargue más rápido y el servidor web tenga más recursos disponibles para otros procesos.

    Esto lo podremos cambiar desde el menú Sistema > Configuración, bajo el menú lateral Desarrollador, dentro encontraremos las secciones Javascript Settings y CSS Settings, en las cuales podremos activar o desactivar el merge de archivos.

    Compresión de la información mod_deflate
    La compresión de información HTTP es un método para acelerar la carga de las páginas web.

    Al enviar la información comprimida, se necesita menos ancho de banda para transferir una página web resultando esto en que la página carga más rápido.

    Por defecto este tipo de compresión en Magento está deshabilitada, podemos activarla fácilmente modificando el fichero .htaccess de nuestra instalación de Magento,

    Desactivar logs de visitas de Magento
    Por defecto en nuestra instalación de Magento tenemos activado un sistema de logs el cual está guardando continuamente los accesos de los usuarios, esto en la práctica no se suele usar, ya que hay sistemas más eficientes de estadísticas como Google Analytics que además no cargan el sistema innecesariamente.

    Es muy recomendable tener desactivada estas opciones ya que cuantos más usuarios haya conectados más carga innecesaria generamos en nuestro servidor MySQL.

    Esta sobrecarga de accesos puede aumentar considerablemente la carga de la web y el tamaño de la base de datos, pudiendo reducir fácilmente un 80-90% el tamaño de la base de datos solo limpiando las tablas de logs.

    Para cambiar este parámetro fácilmente lo podremos hacer accediendo a Sistema > Configuración, en el menú lateral de la izquierda bajo la sección Avanzado > Sistema, dentro vemos la sección Log, hay una opción para versiones recientes de Magento que es: Enable Log, la podemos poner a “No”, así no registrará ciertas acciones.

    Adicionalmente, se puede configurar el cron para que limpie más a menudo estas tablas, por lo que podríamos poner que la limpieza sea diaria, teniendo más limpias las tablas y manteniendo el resto de funcionalidades de Magento.

    No es recomendable deshabilitarlos desactivando el módulo Mage_Log directamente, ya que si en el código deseas debugear, no podrás. Lo mismo le ocurrirá a extensiones de terceros que quieran sacar debugs, al estar este módulo desactivado no podrían generarse.

    Hay casos en los que por la cantidad de datos o limitaciones del servidor, la herramienta integrada de Magento no podrá realizar/completar dicha limpieza o nos resulte más conveniente hacerlo de otro modo, en tal caso tenemos estas opciones:

    A) Hacerlo por MySQL, usando PHPMyAdmin o la linea de comandos:

    A partir de aquí son los relacionados con las exportaciones e importaciones o los productos recientemente comparados o vistos por los clientes, información que no es imprescindible:

    B) Usar un script, como el nuestro, para realizar limpieza en una o varias instalaciones de Magento, podéis descargarlo, y colaborar, aqui:

    https://github.com/factoriadigital/magento-maintenance-script

    Este script, para Magento 1.x, hace lo siguiente:

    1. Limpia las tablas de log de visitas con más de X días de antigüedad, por defecto 7 días, con la herramienta interna de Magento (equivalente a ejecutar php -f shell/log.php).
    2. Crea una copia comprimida y borra los ficheros de log y report con más de X días de antigüedad, por defecto 30 días.
    3. Borra las sesiones con más de X días de antigüedad, por defecto 7 días.
    4. Borra los thumbnails con más de X días de antigüedad, por defecto 180 días, se regeneran solos si se carga la página de producto.
    Compilador de Magento

    [​IMG]

    Este módulo se encarga de localizar los ficheros PHP que se encuentren en diferentes directorios y los ubica en un mismo directorio, de esta forma los localiza rápidamente sin tener que buscarlos, lo cual reduce el tiempo de generación de la página web.

    No es recomendable que cuando se vaya a actualizar Magento o se vaya a instalar una nueva extensión esté activo, ya que nos puede derivar en errores, por lo que la mejor forma sería desactivarlo primero, instalar o actualizar nuestra extensión o Magento y posteriormente activarlo nuevamente.

    Para activar o desactivar esta característica, lo realizaremos bajo el menú Sistema > Herramientas > Compilación

    Caches internos de Magento y variables de sesión
    Magento se acelera en gran medida haciendo que utilice un caché interno para los 2 niveles de caches. El sistema elegido dependerá de nuestra configuración de servidor(es):

    Hosting compartido
    si admite algun tipo de cache como APC. Xcache, Zend, etc con una memoria y permisos suficientes para almacenar ficheros es nuestra mejor opción.

    Es importante testar después de activarlo ya que puede que no hayan habilitado suficiente memoria por usuario o no estar configurado correctamente y no funcionar en la práctica. Si falla, la siguiente opción más rápida es activar el cache de ficheros.

    VPS o servidor dedicado
    Una opción sencilla y eficaz es configurar el cache de magento como filesystem y luego crear unas particiones en memoria de los directorios de cache y sesiones, evitando así accesos de disco duro y las operaciones de carga de las páginas web resultarán más rápidas.

    Ya que estos directorios los creamos con memoria, serán de un tamaño limitado, es recomendable mediante tareas de crontab limpiar los ficheros que tengan más de 1 dia de antigüedad. Estos directorios se llenarán más o menos rápido dependiendo de la variedad de artículos que disponga nuestra tienda online.

    Para crear estos directorios de memoria puedes usar estos comandos de ejemplo, modificandolos con tu ruta de servidor:

    Escogemos esta configuración sobre Memcached o Redis ya que estamos accediendo directamente a nivel de sistema operativo, evitando el overhead de las conexiones y/o la pila de PHP, lo cual suele redundar en un mayor rendimiento con un menor gasto de recursos.

    Continúa en el segundo post
     
  2.  
    Comunidad Magento orgullosamente patrocinada por el hosting y vps magento de FactoriaDigital.com.
  3. factoriadigital

    factoriadigital Administrator Miembro del equipo

    68
    0
    6
    Cluster de servidores
    El almacenamiento de las sesiones en MySQL tiende a emplearse cuando queremos tener un clúster de servidores para nuestra tienda virtual y compartan sesión todos los frontend web, por si un usuario cambia de servidor se siga manteniendo la sesión del usuario. Esta opción carga innecesariamente la base de datos, especialmente en situaciones de gran concurrencia.

    Para este escenario lo más óptimo sería tener un pool de Memcache o Redis y que los frontend conectaran directamente.

    Ahí aparte de los caches internos del Magento podremos poner también las sesiones de usuarios, pudiendo compartir la sesión entre todos los servidores fácilmente.

    Memcache es una opción relativamente sencilla y eficaz, especialmente si solo trabajamos con un servidor de caché. Si necesitamos más de un servidor de caché, por necesidad de recursos o alta disponibilidad, Redis es la opción a usar (soportado oficialmente desde Magento 1.8)

    En ambos casos, definiremos un pool de memoria donde podremos guardar las operaciones realizadas por Magento y también las variables de sesión.

    Al tratarse de un caché en RAM carga mucho más rápido que si tiene que ir accediendo al disco duro, acelerando bastante la carga de las páginas web.

    Cuanto más grande sea el pool, más información se podrá almacenar. Este pool puede estar en otro servidor distinto al de Magento y ser utilizado por varias instalaciones de Magento para formar un clúster en que todas las instalaciones comparten el mismo pool de caches y el pool de sesiones de usuario.

    Es importante que una vez activado se limpie manualmente el directorio de caché para evitar errores.

    Si se va a realizar modificaciones en la plantilla es recomendable limpiar el caché del sistema que usemos después de realizar los cambios.

    Cuantas más cosas hagamos que sean usadas en memoria, más rápido funcionará nuestra instalación de Magento, soportando mejor una mayor demanda de peticiones sin crear cuellos de botella debidos a los accesos al disco duro.

    PHP y sus caches
    Versión de PHP (o HHVM)
    La versión de PHP va a venir determinada por la versión de Magento:

    Magento 2: PHP 7.x

    Magento 1.x: Máximo PHP 5.6, aunque determinadas versiones se pueden parchear para funcionar con PHP 7 mediante una extensión que lo parchea: https://github.com/Inchoo/Inchoo_PHP7

    Otra opción es usar HHVM, el cual funciona muy bien con versiones antiguas de Magento (incluso las que soportan como máximo PHP 5.3) y da un rendimiento muy similar al de PHP 7.

    En líneas generales, el mejor rendimiento se obtiene con PHP 7 o HHVM. S no podéis, utilizad PHP 5.6 o la versión más alta que os permita vuestro Magento, así como sus extensiones y plantillas.

    Opcode Cache
    En todos los casos, si usáis PHP 5.5 o superior es fundamental activar y configurar OpCache, ya que viene por defecto en PHP 5.5 o superior y tiene extensión para versiones inferiores hasta PHP 5.2. Hay otras opciones como APC, Xcache, Eaccelerator, etc, pero en la práctica el rendimiento es muy similar, con lo cual, lo mejor sería optar por la opción más compatible.

    Servidores web y su configuración
    En la configuración de nuestro Apache a la hora de procesar los ficheros PHP se puede escoger de qué forma procesarlos, lo más estándares es DSO, SUPHP y FastCGI.

    – DSO : inseguro en entornos compartidos, más rápido, soporta opcode caché.

    – SuPHP : más seguro en entornos compartidos, no tan rápido, NO soporta opcode caché.

    – FastCGI : rápido, soporta opcode caché, complicado de configurar.

    Uno de los servidores webs más rápidos y que mejor optimizan la memoria es Litespeed u OpenLiteSpeed. Soporta altas cargas de usuarios, opcodecache y todos sus procesos están enjaulados. Además tiene un rendimiento similar a NGiNX pero con compatibilidad completa con .htaccess, lo cual nos evita tener que reescribir estas reglas, que pueden ser bastante complejas.

    Full Page Cache y proxys inversos:
    Podéis usar NGINX o Varnish como proxy inverso junto con Apache, pero requiere una configuración más compleja para que Magento, especialmente la version 1.x, no de errores.

    Si queremos algo rápido de implementar y eficaz, recomendamos usar un módulo de FPC, externo en Magento 1, siendo el más popular el de Amasty aunque hay diversas opciones, o el FPC integrado en Magento 2, o LiteSpeed con LiteMage, dependiendo de nuestro presupuesto y tiempo para implementar.

    Generalmente, para obtener el máximo rendimiento con estos sistemas de FPC vamos a tener que modificar nuestras plantillas para que hagan un uso más completo del cache, especialmente en el carrito de pedidos, pero incluso sin eso nos darán un buen aceleron en el resto de páginas del catalogo.

    Motor de base de datos MySQL
    Como norma general recomendamos MySQL 5.6, pudiendo usar 5.7 con Magento 2.

    En muchos hosting usan MySQL 5.1 o 5.5 por compatibilidades con otras aplicaciones, pero si podéis, la mejor opción sería utilizar MySQL 5.6, ya que la diferencia de rendimiento puede ser de más del doble respecto a la 5.5.

    En la versión de MySQL 5.5 el motor de InnoDB fue totalmente reescrito siendo ahora el motor de la base de datos predefinido, y esto se ha mejorado aún más en MySQL 5.6.

    Magento hace un uso intensivo de las tablas en InnoDB y nos beneficia especialmente.

    También hace un mejor uso de las CPU multicore con lo cual aprovechará más eficientemente los cores de las mismas.

    En el caso de que queramos montar un clúster de servidores MySQL para nuestra base de datos de Magento, también trae mejoras en la réplica de datos.

    Si no podéis cambiar a MySQL 5.6 pero podéis cambiar el motor de base de datos, os recomendamos Percona o MariaDB que son compatibles a nivel binario con MySQL 5.1 y 5.5

    Optimización MySQL
    Magento hace un uso muy intenso de la base de datos, por ello es de suma importancia que este bien configurado. Debe disponer de bastante memoria RAM y tener unos parámetros adecuados para que las consultas de Magento sean rápidas y eviten crear cuellos de botella en el disco duro.

    Un parámetro muy importante es innodb_buffer_pool_size que tendremos que adecuar a la memoria que dispongamos en el servidor o VPS. Cuanto más generosos seamos añadiendo memoria RAM al MySQL, mejor funcionará Magento.

    Otro parámetro muy importante es activar el query_cache y definir query_cache_size . En este caso no es recomendable poner un tamaño demasiado grande ya que podemos obtener el resultado contrario al esperado.

    Una herramienta que nos puede ayudar si no tenemos un experto a mano es MySQLTuner, gratuita y que podemos obtener y ejecutar desde ssh de la siguiente forma:




    Al ejecutarla hará un análisis de nuestro servidor MySQL y su configuración y nos pondrá una serie de recomendaciones de utilidad para aplicar a nuestra configuración de MySQL.

    Conclusiones
    Espero que este texto os haya sido de utilidad y os haya aclarado cómo aumentar el rendimiento para la mayor parte de casos que os encontréis.

    Este documento está abierto a comentarios, dudas y sugerencias, os invito a comentar.

    PD: Esta charla la publicamos originalmente en nuestro blog, pero creo que aquí va a ser mucho más útil para la comunidad.
     
Cargando...

Compartir esta página

Cargando...