Estoy ejecutando Opencart 1.5.2 en mi servidor y después de importar una gran cantidad de productos obtuve una velocidad enorme. Intenté instalar un vq mod que tuvo que acelerar el sitio ... no lo hizo.Velocidad de carga extremadamente lenta de Opencart
sé que tengo algunos elementos en el sitio que son relativamente grandes, pero antes de la importación que estaba funcionando bien.
El recuento de productos en las categorías es una fuente importante de cargas de página lenta en OpenCart. Hay algunos lugares en los que esto podría calcularse y tendrá que deshacerse de todos ellos para notar una mejora en el tiempo de carga de la página debido a este factor.
Si edita el módulo Catalog puede desactivar la cuenta de producto para el menú de navegación (que aparece en la columna de la izquierda por defecto) mediante el establecimiento de Product Count: a Disabled.
El tema predeterminado también tiene un recuento de productos que se muestra en el menú principal del sitio. Puede encontrar este código en Catálogo/controlador/common/header.php:
$product_total = $this->model_catalog_product->getTotalProducts($data);
$children_data[] = array(
'name' => $child['name'] . ' (' . $product_total . ')',
'href' => $this->url->link('product/category', 'path=' . $category['category_id'] . '_' . $child['category_id'])
);
elimine o comente cualquier referencia a $product_total:
//$product_total = $this->model_catalog_product->getTotalProducts($data);
$children_data[] = array(
'name' => $child['name'],
'href' => $this->url->link('product/category', 'path=' . $category['category_id'] . '_' . $child['category_id'])
);
Eso debería hacerse cargo de todas las referencias en una instalación predeterminada de OpenCart, pero si está utilizando un tema personalizado o módulos, podría haber más. De manera más general, puede buscar todo el catálogo/directorio para referencias al model_catalog_product->getTotalProducts().
Si busca otras referencias a getTotalProducts() Asegúrese de no eliminar las referencias que usan el recuento de producto para la paginación, de lo contrario, la paginación no funcionará correctamente. Aquí hay un ejemplo del catalog/controller/product/search.php, un archivo que necesita el conteo del producto para funcionar correctamente.
$pagination->total = $product_total;
La eliminación de estas referencias ha llevado a casi un tiempo de carga de 10 veces la aceleración de la página en mis servidores de desarrollo en una instalación con opencart ~ 2.000 productos.
Echa un vistazo a catalog/controller/module/categories.php. Por defecto, el módulo de categoría muestra el recuento de productos al lado de cada elemento en el menú. Esto resulta en un poco de sobrecarga de consulta para una ganancia de ux muy pequeña (en mi opinión).
La línea
$product_total = $this->model_catalog_product->getTotalProducts($data);
aparece dos veces, si coméntela (y donde se utiliza $product_total debajo de ella) debería ver ganancias muy significativas.
Lo tengo resuelto. Parece que hay un "nuevo" enfoque en las consultas SQL descubiertas por el equipo de OC y debe llamarse "DDoS hasta la muerte".
La base de productos ahora ha crecido a 37k productos en 129 categorías (desde 18k durante la noche, lol ... no debería haber escrito ese scripts automatizados de importación y dárselo a un lamer ...) y los tiempos de carga han crecido de 6-12 segundos a 20-25 segundos, golpeando el servidor SQL duro:
[cita] Вопросов начиная с запуска: 514,064,911 (ques desde el arranque) ø в час: 1.301.788 (promedio ques por hora) ø в минуту: 21.696 (ques medio para los minutos) ø в секунду: 362 (ques medio para los segundos) [/ quote]
Esto no es normal, puesto que hay 2 usuarios en el sistema - la secuencia de comandos automatizada (limitada - 30 preguntas por segundo, luego dormir (1)) y yo (362-30 = 332 consultas por segundo? por un humano? WTF desarrolladores?). De acuerdo con esta OC de estadísticas, de esta manera se necesitará una granja de servidores seria para atender a más de 500 usuarios al mismo tiempo. No va a pasar. No en esta vida
Mantengo varios sitios web y he reescrito casi todos. Mi sitio más visitado (200k visitas por día) está generando "solo" 2.5Mil ques por día. Y es pesado (contenido), créanme. Si OC se cargara por igual (200k vistas) esto significaría que habría 100-120Mil ques por día.
TAMBIÉN las consultas no son tan acertadas, dando al servidor tiempos difíciles con ORDER BY (como sospechaba) y SELECT DISTINCT (¡¡¡dolor !!!).
TAMBIÉN hay numerosas opciones establecidas para cada consulta, sin importar si el usuario las ha configurado o no (ordenación, orden, etc.). Esto hace preguntas como 4-5 veces más largas de lo esperado, incluso si el usuario no quiere ningún orden de clasificación (ASC, DESC, etc.)
TAMBIÉN hay preguntas escritas de una manera tan mala, que me divierte. ¿Cómo podría extraer números totales para cualquier cosa utilizando 5 phps y 3 consultas, siempre que pueda hacer una línea simple 1 "SELECT COUNT (*) FROM ..."? Al equipo de OC no parece importarle los tiempos de ejecución ni las cargas del servidor.
Me gustaría pedir disculpas si alguien se ofende por lo que he escrito, pero en mi caso estoy en lo cierto: todo el enfoque es incorrecto para lograr los objetivos (ejecución rápida en 37k productos/129 gatos). OC podría ser bueno para alguien con 2 categorías y 50 productos (¿lol?). No sé. Y probablemente no me entere.
Como INFO, el almacenamiento en caché no es una solución. El almacenamiento en el lado del servidor es bastante bonito. Cualquier cosa más allá de esto significa que tienes serios problemas de codificación. Entonces no ... Voy a repetir NO COMPRE módulos de caché. Están ocultando los problemas, no los están resolviendo. Si un módulo de almacenamiento en caché puede ocultar el problema en productos de 40k, no podrá hacerlo en productos de 140k. Necesitará un módulo de almacenamiento en caché para el módulo de almacenamiento en caché, lol.
Ahora, a la solución. Camino fácil. Modificaremos solo los problemas principales. No explicaré las modificaciones que hice en mi versión, porque están en muchos archivos y son fundamentales si no entiendes lo que estás haciendo (es posible que pierdas opciones de OC que te gustaría conservar, mientras que a mí no me importa sobre opciones siempre que el sitio se cargue durante medio minuto). Entonces, SOLAMENTE modificaciones menores.
Wil dice - explicado para la versión 1.5.5.1 stock, stock theme. Medios: sin modificaciones. Después de la modificación, perderá el bloque del lado izquierdo con categorías, pero su sitio cargará REALMENTE RÁPIDO (37k products/129 cats -> 0.137 segundos avg en 5 cargas sumas, la distancia del servidor es ~ 200mi)
0) RESPALDA su sitio. Vamos a modificar los archivos. Podrías hacer un desastre horrible. Y llorar después.
1) Obtener/catalogar/controlador/producto/categoría.php línea Encontrar: 184
Debe contener: $product_total = $this->model_catalog_product->getTotalProducts($data);
Reemplazar con: //$product_total = $this->model_catalog_product->getTotalProducts($data);
Descripción: Comentando cuentan categorías, ya que toma bastante DAMD mucho que contar productos en 129 categorías (129 consultas WTF.? ?)
2) Obtener /catalog/controller/product/category.php línea Encontrar: 187
debe contener: 'name' => $result['name'] . ($this->config->get('config_product_count') ? ' (' . $product_total . ')' : ''),
Reemplazar con: 'name' => $result['name'],
Descripción: La limpieza - no hay recuento que se muestra en categorías, como `t contar con ellos nunca más.
3) Obtener /catalog/controller/product/category.php línea Encontrar: 388 debe contener: 'common/column_left',
Reemplazar con: // 'common/column_left',
Descripción: generación Skippng de la columna de la izquierda en la categoría ver.
4) Obtener /catalog/controller/product/product.php línea Encontrar: 463 debe contener: 'common/column_left',
Reemplazar con: // 'common/column_left',
Descripción: generación Skippng de la columna de la izquierda a la vista de producto .
5) Obtener /store/catalog/view/theme/default/template/product/product.tpl línea Encontrar: 1
debe contener: <?php echo $header; ?><?php echo $column_left; ?><?php echo $column_right; ?>
Reemplazar con: <?php echo $header; ?><?php echo $column_right; ?>
Descripción: eliminando la columna izquierda del tema - vista de productos.
6) Obtener /store/catalog/view/theme/default/template/product/category.tpl línea Encontrar: 1
debe contener: <?php echo $header; ?><?php echo $column_left; ?><?php echo $column_right; ?>
Reemplazar con: <?php echo $header; ?><?php echo $column_right; ?>
Descripción: Eliminar columna izquierda del tema - vista de catálogo.
HECHO. Pon a prueba tu velocidad de carga. Debería ser bastante sorprendente, si tu problema era como el mío.
NOTA: Tenga en cuenta que no estoy familiarizado con ninguna versión de OC y nunca la he usado antes. Como hemos resuelto parte del problema, no está completamente resuelto. Esta es una solución temporal. Eliminar las piezas que provocan una carga lenta es una solución hasta que las vuelva a escribir, esta vez con suerte. Estoy dispuesto a reescribirlo, si alguien quiere superar a mi jefe. Puedo tomar vacaciones y trabajar para usted:) Mi pago actualmente es de 4700 € por semana.Comprender y reescribir esta columna de la izquierda de la manera correcta no debería tomar más de 1-2 días hábiles.
PP. Publicaré esto en varios lugares, porque no creo que al equipo de desarrollo OC le guste lo que ha leído, no importa que no quiera ofenderlos, solo para señalar los errores críticos que han cometido (25.31 tiempo de carga promedio) para cada página en pruebas, ningún cliente esperará más de 3-4 segundos antes de irse a otro sitio. ¿Dafuq?). Y al no dejarme publicar esta información, la gente no sabe cómo salir del problema e ir a comprar un "módulo de almacenamiento en caché" que en realidad está copiando los archivos del disco duro como algo salvaje. Desperdicio de dinero, desperdicio de recursos de disco duro, desperdicio de electricidad ... y todo esto: para crear una ilusión todo funciona bien, mientras que no funciona.
Para muchos cambios principales – TheBlackBenzKid
Este método ayuda mucho. ¡Gracias! –
Lo tengo resuelto. Parece que hay un "nuevo" enfoque en las consultas SQL descubiertas por el equipo de OC y debe llamarse "DDoS hasta la muerte". +1 – Jordy
Quizás necesite Full Page Cache aka FPC está hecho para acelerar su tienda creando archivos simples para cargar en lugar de todo el framework opencart. Esta extensión almacenará en caché todas las páginas del catálogo, pero mantendrá la información específica del usuario dinámica.
Enlace: Full Page Cache
he encontrado otra solución al problema. Básicamente, MySQL se está ahogando cuando intenta filtrar los resultados de las consultas de las tablas Product_category y Product_Tag simultáneamente. Escribí un vqMod para OC 1.5.2.1 que reemplaza la función getTotalProducts() y construye consultas SQL individuales para ser ejecutadas contra las 2 tablas. A continuación, usa un SQL UNION para vincular los resultados de ambas consultas. Esta solución mejora el rendimiento y le permite seguir usando los contadores de productos en su sitio.
¡Esto llevó mi página a un tiempo de carga de 45 a 50 segundos hasta menos de 1 segundo!
Me acaba de publicar el archivo vqMod aquí: http://www.opencart.com/index.php?route=extension/extension/info&token=7bc7d0149c7101c3d336b2e0b29e3f03&extension_id=13155
, hágamelo saber si usted tiene alguna pregunta y te ayudaré en lo que pueda.
Si tiene habilitado seo urls en su carro abierto, puede ser una fuente importante de lentitud.
Tengo oc v1.5.5.1 con aproximadamente 3K categorías y 40K productos. Lo ejecuto en hosting compartido, y al principio mis tiempos de carga eran de aproximadamente 40 segundos o más. Luego obtuve un poco más en OpenCart, y me di cuenta de que está haciendo una gran cantidad de solicitudes en la tabla oc_url_alias en la base de datos oc. Así que mi consejo es:
1. Add index to query column in oc_url_alias table
Con esta mis tiempos de carga bajaron a unos 7 segundos por página.
2. Add index to keyword column in oc_url_alias table
Después de dos pasos que lo tiene hasta unos 1-3 segundos por página.
Ahora mi OC se está ejecutando en aproximadamente 1 segundo por cada página, he conseguido que mediante la adición de algunos más índices en mi tabla de MySQL, de acuerdo con el post de este tipo http://bloke.org/php/opencart-is-slow-with-many-categories/, que son:
Index on parent_id column in category tableIndex on category_id column in product_to_category tableIndex on language_id column in category_description tableIndex on store_id column in category_to_store tableIndex on attribute_id AND language_id columns in product_attribute tableIndex on manufacturer_id column in product tableIndex on language_id column in product_description tableIndex on store_id column in product_to_store tableAdemás, como se mencionó anteriormente en otras respuestas, que también se elimina el recuento producto en: catalog/controller/product/category.php y catalog/controller/module/categories.php. Si aún experimenta lentitud, puede deshabilitar completamente el módulo de categorías de la barra lateral.
Por último, puede intentar utilizar esta extensión: http://www.opencart.com/index.php?route=extension/extension/info&extension_id=10464, pero no soporta URLs SEO como es, así que tuve que ajustar un poco (decodificando $_REQUEST['_route_'] parámetro, que contiene solicitud de URL SEO, en función de run)
Hola. ¿Podría compartir esa solución para el seo url fpc? – geryjuhasz
Tenga una mirada en el archivo .htaccess, como se explica en this tutorial:
`## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/pdf "access plus 1 week"
ExpiresByType text/x-javascript "access plus 1 week"
ExpiresByType application/x-shockwave-flash "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 week"
ExpiresDefault "access plus 1 week"
</IfModule>
## EXPIRES CACHING ##`
En una tienda de trabajo en la que es 1.5.6.4_rc Versión (estoy bastante seguro de que se aplica ot su versión también) la problema fue con lo siguiente:
foreach ($ categorías como $ categoría) en el catálogo/controlador/módulo/category.php alrededor de la línea 33
foreach ($ categorías como $ categoría en el catálogo/controlador/common/cabecera .php alrededor de la línea 107
Debido a ese código, tuvimos más de 900 consultas de DB desde $ this-> url-> link() junto con varias otras.
hemos creado un vqmod para hacer frente a este problema mediante el almacenamiento en caché esta categoría de datos por lo que al menos que sólo ocurrirá cuando la caché se regenera:
<modification>
<id>Cache category data to speed up page load for store with many categories and sub categories.</id>
<version>1.0.0</version>
<vqmver>2.3.2</vqmver>
<author>Weismann Web</author>
<file name="catalog/controller/module/category.php">
<operation>
<search position="after"><![CDATA[
foreach ($categories as $category) {
]]></search>
<add><![CDATA[
$category_data = $this->cache->get('vqmod_category_data_controller_module_category');
if ($category_data) {
$this->data['categories'] = $category_data;
break;
}
]]></add>
</operation>
<operation>
<search position="before"><![CDATA[
if (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/module/category.tpl')) {
]]></search>
<add><![CDATA[
if (!$category_data) {
$this->cache->set('vqmod_category_data_controller_module_category', $this->data['categories']);
}
]]></add>
</operation>
</file>
<file name="catalog/controller/common/header.php">
<operation>
<search position="after"><![CDATA[
foreach ($categories as $category) {
]]></search>
<add><![CDATA[
$category_data = $this->cache->get('vqmod_category_data_controller_common_header');
if ($category_data) {
$this->data['categories'] = $category_data;
break;
}
]]></add>
</operation>
<operation>
<search position="before"><![CDATA[
$this->children = array(
]]></search>
<add><![CDATA[
if (!$category_data) {
$this->cache->set('vqmod_category_data_controller_common_header', $this->data['categories']);
}
]]></add>
</operation>
</file>
</modification>
Aquí es mi post sobre ello en los foros opencart: Issue With Slow Opencart When Having Lots of Categories
Esto es lo que lo solucionó. Como los carteles anteriores han mencionado una de las principales causas de la desaceleración es en:
catálogo/modelo/catálogo/producto.php -> función pública getTotalProducts ($ data = array()) { ...
poner esto en el comienzo de la función:
public function getTotalProducts($data = array()) {
if (isset($_SESSION['totalproducts'.$_SERVER['QUERY_STRING']])){
return $_SESSION['totalproducts'.$_SERVER['QUERY_STRING']];
}
Ponga esto al final
$_SESSION['totalproducts'.$_SERVER['QUERY_STRING']] = $query->row['total'];
return $query->row['total'];
}
De esta manera usted no tiene que comentar nada, pero los productos totales serían estar equivocado si se actualizó mientras una sesión estaba activa.
Espero que ayude.
Debe crear 02 índices para las columnas de palabras clave y de consulta en la tabla OC_URL_ALIAS. Estarás impresionado con la velocidad. Utilicé PageSpeed Insight de Google para medir la velocidad de mi sitio web. En la primera vez, el resultado es "En nuestra prueba, su servidor respondió en 12.2 segundos". Después de crear dos índices, el tiempo de respuesta es 7.8 segundos :)
Sé que ya hay algunas respuestas, pero algo que sí ayuda es tener un servidor dedicado y un servidor de base de datos dedicado. – TheBlackBenzKid