Posterior a observar en diferentes repositorios y sitios de internet finalmente descubrimos la respuesta que te enseñamos pronto.
Solución:
El administrador es más lento que el frontend por varias razones:
- no hace uso de demasiado almacenamiento en caché (por ejemplo, sin almacenamiento en caché de bloques)
- no utilizará las tablas “planas” para obtener datos de productos y categorías
- tiene muchas operaciones con el potencial de ser lento
Ahora, depende de lo que entiendas por lento. Si piensas 1s-5s tiempo de respuesta es demasiado lento, no hay mucho que puedas hacer. Pero si su tiempo de respuesta está en el rango de decenas de segundos, algo anda mal.
Como comentaron otros, el tamaño del catálogo es un factor importante. Cuanto más grande sea, más tardará la operación de guardar el producto. Esto no se debe a que el producto se guarde en sí mismo, sino al hecho de que los índices deben actualizarse. Una forma rápida de acelerar el sitio es configurar los indexadores en modo manual. Esto hará que las operaciones de guardado sean razonablemente rápidas, pero tiene la desventaja de no mostrar los cambios en el front-end en tiempo real (este es el punto central de los índices “al guardar”). Tenemos configuraciones en las que tenemos parte de los indexadores configurados en manual (el primer sospechoso es siempre la reescritura de URL del catálogo) y un cron “reindexar todo” programado diariamente. Si bien los administradores del sitio estarían más felices de no tener que esperar ~ 1 día para que aparezcan algunos cambios en el sitio, es un compromiso que generalmente funciona.
Otra razón menos común que he visto para ralentizar las operaciones de guardado es Enterprise Full Page Cache. Magento intentará eliminar de manera inteligente las partes almacenadas en caché relacionadas con el elemento que cambia/elimina para que los cambios sean visibles al instante. Esto nunca es un problema con el almacenamiento en caché de bloques, ya que no puede haber demasiadas entradas en caché de todos modos, pero el caché de página completa, el almacenamiento en caché en URL, puede intentar eliminar millones de entradas a la vez, lo que será lento sin importar el backend de caché. Cambiamos el código para poner en cola la operación de eliminación de caché y ejecutarlo en tiempo de cron.
Como última razón para los administradores lentos, ¿quizás esto sea solo un subproducto de la sobrecarga del servidor? Si bien algunas páginas almacenadas en caché pueden aparecer rápidamente, tal vez todas las demás sean lentas. ¿Cómo es la página de pago? ¿Más rápido o tan lento como las páginas de administración? Debe observar la carga del servidor, es más barato y más rápido aumentar la capacidad del hardware que hacer cambios en el código si tiene sentido.
Recuerde que no es suficiente usar APC como un objeto de caché de código de operación. También debe configurarse correctamente para manejar lo que le arrojas. Realizamos revisiones de rendimiento de los entornos para los clientes y, muchas veces, APC se configura básicamente con la configuración predeterminada. Los valores predeterminados simplemente no son suficientes para Magento. Con los valores predeterminados, no hay suficiente memoria asignada para almacenar el código base, y mucho menos usarlo como caché de objetos. Terminas con tasas de fallas realmente altas frente a una tasa de fallas cercana a 0. En la mayoría de los casos, hemos descubierto que necesita al menos 256 millones asignados a APC.
Aquí hay una muestra de lo que generalmente usamos como línea de base:
extension=apc.so
apc.shm_size=256M
apc.mmap_file_mask=/apc.shm.XXXXXX
apc.include_once_override=0
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=10000
apc.user_entries_hint=10000
apc.stat=0
apc.enable_cli=1
apc.max_file_size=5M
apc.slam_defense=0
También es posible que tenga problemas de escalabilidad con el backend de caché de archivos predeterminado. Cuando se usa el backend de APC, realmente usa APC+File, ya que APC no admite etiquetas que se necesitan al vaciar la memoria caché por tipo.
Redis puede solucionar el problema por usted, ya que es mucho mejor para escalar. Pero Magento 1.8 también incluye un servidor de archivos mejorado que no tiene los mismos problemas de escalado, es básicamente una versión renombrada del trabajo de Colin Mollenhour, https://github.com/colinmollenhour/Cm_Cache_Backend_File. Tal vez sea una mejor opción que Redis si está en un solo servidor o no puede instalar Redis por cualquier motivo.
Lo mejor que hicimos para acelerar significativamente el backend es instalar REDIS como controlador de caché. Ahora también es compatible con el núcleo de Magento 1.8 y versiones posteriores.
Nada se compara… ahora es click click clickerdy click
http://www.magentocommerce.com/knowledge-base/entry/redis-magento-ce-ee
Además, podría considerar agregar la extensión Redis Session para agregar también sesiones al servidor de memoria redis …
La mejor manera hasta la fecha de acelerar las operaciones de back-end es usar uno o, preferiblemente, todos los siguientes
- habilitar caché en Magento
- minificar css y js
- habilitar algún tipo de almacenamiento en caché de código de operación php
- habilite caché y gzip a nivel de servidor a través de htaccess o ngunx
- habilite Redis para caché en Magento (¡mejor!)
- habilitar la administración de sesiones de redis
- echa un vistazo a la indexación asíncrona de mirasvit (los productos ahora se guardan en ms)
¡Buena suerte!
Si aceptas, eres capaz de dejar una noticia acerca de qué le añadirías a esta reseña.