aws php magento amazon-web-services amazon-ec2 amazon-rds

php - aws - ¿Cuál es el mejor método para remediar el retraso de Magento con más de 20,000 productos?



install magento in aws (3)

Pruebe la extensión de caché de página completa de Brim . Es muy bueno uno

Estoy ejecutando magento en 3 instancias de Amazon EC2. Una está configurada para acceder directamente al panel de administración, las otras dos están ubicadas detrás de un equilibrador de carga.

Las cosas funcionaron sin problemas hasta que importamos nuestros datos con 20k + productos, cada uno un producto configurable con ~ 4 productos simples (para diferentes tamaños, colores, etc.)

Las únicas cosas que funcionan lentamente parecen ser cosas que pasan por encima de los productos: tanto las páginas del administrador como las del catálogo frontend tardan entre 5 y 10 segundos para obtener una respuesta del servidor. Las páginas estáticas / CMS cargan bien.

Están todos conectados a la única base de datos RDS MySQL que funciona bien: puedo hacer consultas y recuperarlas rápidamente.

Tenemos todo el almacenamiento en caché (incluida la memoria caché de página completa) habilitado y hemos habilitado catálogos planos sin un cambio real en la velocidad.

Los directorios magento son independientes por servidor, a excepción del media/ directorio que se mantiene sincronizado con lsyncd . El servidor de administración se comporta como maestro y los dos servidores frontend de carga equilibrada son los esclavos.

Vamos a desglosar esto:

  1. Supuestos que haré (márquelos)

    • Se está ejecutando en instancias EC2 bastante potentes, por ejemplo, m3.large
    • Está ejecutando un caché de PHP como APC
    • Está utilizando el compilador Magento sistema-> herramientas-> compilación
    • Estás usando un servidor web Apache
    • ''De 5 a 10 segundos para obtener una respuesta del servidor'' significa el tiempo de respuesta y no incluye la imagen y el tiempo de descarga de CSS y JS en el navegador
    • Tiene tablas planas para productos y categorías (pero si su caché está funcionando correctamente, esto no debe dominar la velocidad. También debe ejecutar pruebas sin las tablas planas, no siempre son más rápidas)
    • La configuración de su servidor web está optimizada para el tráfico de alto volumen para ''keep alives'' y ''expires headers''
  1. Comprueba tres veces tu caché de página completa

Lo realmente extraño de tu pregunta es que dices que tienes un caché de página completa, sin embargo, las páginas de front-end de los productos tardan entre 5 y 10 segundos antes de que el servidor los envíe al navegador.

En mi opinión, significa que tu caché de página completa no está funcionando. Un caché de página completa, cuando se implementa correctamente, servirá la página desde Apache directamente sin ejecutar la aplicación Magento ( Mage.php ), por eso es tan rápido. Significa que no hay sobrecarga cuando se solicita una página en caché y es por eso que un sistema de caché de página completa debe tener tiempos ''solicitantes'' de menos de 0.25 segundos y, a veces, menos de 0.1 segundos.

Le sugiero que apague el caché de su página completa y vea qué diferencia hace. Compruebe el tema y la documentación del caché para saber cómo manejan el contenido de la página como el resumen de la cesta y el nombre de usuario, pero cualquier caché debe almacenar en caché todos los bloques de productos, por lo que debe acceder al caché y no acceder al base de datos.

Por supuesto, si tiene 20000 productos (o 100,000? = 20,000 configurados + 4 * 20,000 simples), entonces cada página debe visitarse una vez para llenar sus cachés, por lo que es posible que desee establecer un corrector de enlace que funcione durante la noche para llegar a todas sus URL y el caché de página completa para cada categoría y / o página de producto.

  1. Comprueba los archivos .phtml de tu tema para los temidos

Mage::getModel(catalog/product)->load($_product->getId())

esta línea golpea con fuerza su base de datos y si está haciendo eso para cada producto en una página de categoría, entonces causará problemas. Si su tema está usando ->load() , hable con los diseñadores de su tema sobre cómo crear colecciones con solo los atributos que necesitan. PERO si tienes un caché de página, entonces esto no necesariamente importará (de ahí por qué creo que tu caché no funciona).

  1. Eche un vistazo a su tabla core_url_rewrite

Lo más probable es que esta tabla sea enorme debido a todos los productos que tiene. Puede ayudar a que sus productos simples no sean visibles y solo hagan visibles los configurables en el catálogo y la búsqueda. Comprueba cuántas filas tiene la tabla, truncadla, luego ve al Administrador de Magento y vuelve a indexar las reescrituras; esto volverá a generar la tabla y podrás ver si tiene menos filas (Magento parece duplicar muchas reescrituras durante hora). También obtendrá un conjunto completo de reescrituras para cada tienda en Magento, así que elimine las tiendas que no esté usando.

Ahora otra nota sobre los cachés. Creo que core_url_rewrite uno de los cuellos de botella, así que puse un caché alrededor del .phtml que genera el menú de la tienda porque el menú no cambia mucho y al hacerlo ahorras mucho tiempo en la base de datos. PERO si ya tienes un caché, esto no será un problema a menos que tu caché no funcione o no esté configurada correctamente.

  1. Haz que el perfilador Varien funcione

Para que puedas ver lo que tarda tanto en magento. Creo que deberás desactivar los cachés para que funcione. Esta es una herramienta útil para la creación de perfiles de velocidad , pero existen otras herramientas gratuitas y, en realidad, puede usar el analizador de Varien sin una herramienta. La herramienta le dará una indicación de lo que tardará mucho tiempo en compilarse en la página (pero si su caché está funcionando correctamente, entonces no importará cuánto tiempo construirán los cuentos de la página porque la página se publicará desde el caché que es por eso que creo que tu caché no funciona).

  1. Usted dice ''Base de datos MySQL que funciona bien, puedo hacer consultas y recuperarlas rápidamente''.

Pero esa no es la prueba de si su base de datos funciona bien o no. Tal vez sepa todo esto, pero puede usar phpmyadmin para verificar si su configuración my.cnf está optimizada. phpmyadmin-> status-> consejero le dará sugerencias para innodb_buffer_pool y key_buffer_size y table_cache . Hagas lo que hagas, Magento no tiene índices optimizados, así que mysql siempre tendrá mucho trabajo por hacer. Es posible que desee ver sus archivos innodb como se sugiere aquí (y esto también es obligatorio para leer ), pero si su archivo ibdata1 y sus archivos de registro no son demasiado grandes y no tiene nada en la consulta lenta registros y no está sufriendo demasiadas esperas de bloqueo, entonces tal vez no haya una ventaja para ejecutar con ''innodb_file_per_table'' . Algunas personas sugieren innodb_file_format=Barracuda , pero creo que estamos entrando en el ajuste fino para exprimir el último milisegundo.

Aquí hay una excelente Q & A de sobre archivos ibdata, optimización de tablas y gestión innodb . Advertencia: no conozco la configuración óptima de innagen para Magento, pero cuando leo artículos como ese, creo que parece ser la forma correcta de hacerlo.

De todos modos, debes asegurarte de que my.cnf esté configurado para usar la memoria disponible de la manera óptima (no hay una configuración mágica, no puedo decírtelo, pero estudia estos parámetros:).

max_allowed_packet = table_cache = sort_buffer_size = read_buffer_size = read_rnd_buffer_size = myisam_sort_buffer_size = tmp_table_size = max_heap_table_size = query_cache_size = query_cache_type = thread_cache_size = innodb_fast_shutdown = 0 innodb_file_per_table innodb_buffer_pool_size = innodb_additional_mem_pool_size = innodb_log_file_size = innodb_log_buffer_size = innodb_flush_log_at_trx_commit = innodb_lock_wait_timeout = innodb_thread_concurrency = skip-external-locking max_connections = read_buffer_size = sort_buffer_size = key_buffer_size =

  1. SSH en tus cajas

y ejecute '' top '' para ver la memoria y las cargas de cpu del daemon HTTP y el servidor mysql. A veces hago esto mientras ejecuto mi verificador de enlaces para poder ver el sistema con al menos una pequeña carga. Si hay muy poca carga, tal vez su httpd.conf y my.cnf no están configurados para utilizar la CPU y la memoria disponible. Si su CPU y memoria se están agotando, tal vez necesite cajas más grandes, pero si su caché de página completa está funcionando correctamente ...

El uso de la top también mostrará si su servidor se ha visto comprometido y todos los cilindros de la CPU están siendo acaparados por el bitcoin miner de algún script kiddie.

  1. Tirar dinero en eso

Ir a M3 cajas extra grandes, llamar a Percona y seguir todos sus consejos, obtener una tonelada de RAM y ejecutar su base de datos en un ramdisk, contratar a un chico de Facebook para ejecutar Magento en HHVM, o decir ''atornillar'' y pagarle a un experto de Magento empresa de hosting para que lo haga todo por ti. Pero si su caché de página completa está funcionando ...

----------

De todos modos, espero que te diviertas. Me gusta hacer que Magento corra más rápido. Hay una tonelada de botones para modificar y es muy gratificante ver que los tiempos de carga de la página disminuyen poco a poco.

Oh, creo que el área de administración lenta no será ayudado por el almacenamiento en caché de página completa, pero hay algunos módulos que hacen que la administración de catálogos de productos grandes sea mucho más simple.