Le chargement de la page Magento prend trop de temps

J'ai le site Web de magento. Il n'y a aucun utilisateur (max 2-3 à la fois).

Notre serveur est: CPU: 2000MHz RAM: 2048Mb HDD: 50000Mb.

J'ai installé ZendServerCE (apc + memcached + Zend Optimizer + Zend Data Cache). J'ai désactivé Memcached, car le site Web était bien pire. J'ai défini une structure de type plat, réindexé et mis en cache des données dans la console d'administration.

J'ai donc apc + Zend Optimizer + Zend Data Cache .

1. Le premier problème est que j'ai vérifié à l'exécution comment fonctionne la répartition. L'appel start_session () prend environ 500 à 700 ms. Semble son mauvais résultat. Pourquoi si longtemps, je ne sais pas.

2. J'ai lu celui-ci: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_size et trouvé des options optimales pour mon serveur.

Par heure:

Key_read_requests = 8887
Key_reads         = 252
Key_write_request = 187
Key_writes        = 146 

Vous voyez que 252/8887> 0,01, mais pas trop. C'est la valeur optimale que j'ai jamais obtenue. D'autres résultats ont commencé à partir de> 6.

Voici my.cnf:

key_buffer              = 48M
myisam_sort_buffer      = 2M
sort_buffer             = 2M
read_buffer_size        = 2M
join_buffer             = 2M
read_rnd_buffer         = 2M
max_allowed_packet      = 128M
thread_stack            = 192K
thread_cache_size       = 16
query_cache_type        = 1
myisam-recover         = BACKUP
max_connections        = 50
table_cache            = 256
#thread_concurrency     = 10
query_cache_limit       = 8M
query_cache_size        = 98M

3. Memcached pour une raison quelconque n'était pas bon. Je l'ai éteint. Mais le cache de données zend et l'optimiseur zend fonctionnent toujours.

4. APC semble correct. Pour charger l'action du contrôleur, cela prend 3-4 secondes pour la première fois (j'y place die () pour le vérifier) ​​et pour la première fois cela prend 1 à 1,3 seconde.

5. Après plusieurs minutes, j'ai redémarré mysql, j'ai obtenu un bon résultat. Les pages se chargeaient de 1,5 à 2,5 secondes. Mais maintenant (après plusieurs heures), cela prend 6 à 10 secondes. Je ne trouve pas la raison.

Voyez-vous donc une configuration incorrecte ici? Peut-être que mon serveur ne convient pas à magento?

MISE À JOUR 1: environ 600 catégories et 1000 produits aujourd'hui et environ 20000 catégories (pour différentes boutiques en ligne) et 1500-3000 produits à l'avenir.

Il n'y a pas beaucoup d'attributs.

MISE À JOUR 2 J'ai remarqué que la console ssh fonctionne trop lentement. J'ai redémarré le serveur et maintenant cela fonctionne rapidement. cela signifie que j'ai un problème avec la RAM. Il n'y a pas assez d'espace.

C'est le statut initial sans apache:

             total       used       free     shared    buffers     cached
Mem:          2048        600       1447

MISE À JOUR 3 Je l'ai. Maintenant, il est chargé pendant 0,5-1,5 s

Voici la configuration: mysql

[mysqld]
key_buffer_size         = 256M
tmp_table_size      = 32M
max_heap_table_size     = 32M
myisam_sort_buffer      = 4M
sort_buffer             = 4M
read_buffer_size        = 4M
join_buffer     = 4M
read_rnd_buffer     = 4M
max_allowed_packet  = 64M
thread_stack        = 192K
thread_cache_size       = 16
query_cache_type        = 1
myisam-recover          = BACKUP
max_connections         = 20
table_cache             = 1024
innodb_buffer_pool_size = 128M
query_cache_limit   = 24M
query_cache_size        = 256M

php

[apc]
apc.stat=1
apc.enabled=1
apc.optimization=0
apc.cache_by_default=1
apc.shm_segments=10
apc.shm_size=256M
apc.ttl=0
apc.user_ttl=0
apc.num_files_hint=10000
;apc.mmap_file_mask="/tmp/apc"
apc.max_file_size=5M
apc.enable_cli=1
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.slam_defense=0
apc.user_entries_hint=10000

Tout fonctionne parfaitement, mais une question demeure. APC me montre cette statistique:

Pourquoi frappe si petit? Des idées?

Comme la question ne semble pas très centrée sur Magento, voici ma réponse pas très centrée sur Magento.

La mise en cache OpCode et les optimisations de base de données sont un bon moyen d'accélérer vos applications Web dans une certaine mesure. Mais l'avantage sera relativement modéré. Pour obtenir une augmentation de vitesse réelle, vous devriez envisager d'utiliser le cache de vernis. Il est open source, facile à configurer et facile à intégrer avec magento grâce aux modules disponibles gratuitement pour magento.

Il y a aussi un bon article avec un bref aperçu de son fonctionnement: http://www.fabrizio-branca.de/make-your-magento-store-fly-using-varnish.html

Pensez particulièrement au tableau:

Si votre entreprise dépend de la bonne performance de votre hébergement, pourquoi essayez-vous d'administrer le serveur sans expérience.

Vous bénéficieriez sûrement simplement en contactant un hôte Magento spécialisé et en le laissant s'occuper de l'administration du système, pendant que vous faites ce que vous êtes bon, en gérant votre magasin.

En regardant vos spécifications, vous n'avez pas assez de RAM pour essayer de gérer une boutique Magento. Il y a un tas de questions similaires comme la vôtre,

https://serverfault.com/a/400748/113375 .
/server/430565/magento-hosting-on-a-budget

S'agit-il d'un matériel physique ou d'un serveur privé virtuel? Vous devriez probablement déplacer votre base de données vers son propre serveur dédié. Cela vous donne également l'avantage de pouvoir isoler si vos problèmes de vitesse sont liés à Apache / PHP ou à MySQL.

start_session () étant lent, vous souffrez probablement d'un matériel sous-alimenté. Je ne sais pas si vos choix technologiques signifient que les sessions sont stockées sur disque ou en RAM, mais 500 à 700 ms signifient presque certainement qu'elles sont stockées sur disque et que vous rencontrez des problèmes de performances d'E / S - probablement parce que votre base de données est échanger sur le disque car il ne rentre pas dans la RAM ... mais ce ne sont que des spéculations.

Bonne chance!

Il n'y a évidemment aucun moyen de vous montrer une `` configuration de travail '' qui augmentera vos performances, mais Magento essaie en fait de faire quelque chose comme ça et publie un exemple d'une pile LAMP hautement configurée dans leurs livres blancs sur les performances. La méthodologie de ces livres blancs s'applique à CE et EE. Je recommande fortement de lire complètement les deux livres blancs car les idées suggérées font écho à une grande partie de ce fil et fournissent des recommandations Magento très spécifiques, directement à partir de la source: http://www.magentocommerce.com/whitepaper/

Configuration

ZendFramework (optimiseur zend et cache de données zend) + APC + Memcache + Nginx

fonctionne parfaitement pour moi.

plus de 30 utilisateurs simultanés peuvent charger la page en moins d'une seconde (~ 0.4s-0.6s)

J'ai défini nginx sur 80 ports (en tant que proxy) et apache sur 8080.

Merci à @MattSchweers pour les liens. Je l'ai oublié. Cela m'aide à configurer MySQL

d'après mon expérience, le serveur litespeed augmente les performances 2 fois et vaut bien la licence 1cpu à 32 $ / mois. On m'a dit que vous n'avez besoin que de la licence 1cpu car php fonctionne séparément dans litespeed.

Lorsque vous avez plusieurs boutiques en ligne et plusieurs catégories, Magento crée essentiellement une sorte de produit caretsian d'entrées pour toutes les boutiques en ligne, catégories et produits, ce qui va mettre une charge importante sur la base de données. Vos ratés APC sont assez élevés et vous devrez les examiner. Cependant, même si vous corrigez APC, je pense que votre problème de performances peut persister, surtout si votre trafic augmente.Pour accélérer votre site, vous devrez installer un cache d'opération, soit Varnish, soit Full Page Cache (si Enterprise Edition).

Magento effectue de nombreuses écritures de lecture dans la base de données, vous pouvez également essayer d'avoir votre MySQl dans un mode de réplication maître esclave si toutes les lectures magento de l'esclave étaient en cours, tandis que les écritures arrivent au maître.

J'essaierais de changer les options APC suivantes et de voir si les coups reprennent.

apc.shm_segments 1

apc.ttl 7200

apc.user_ttl 7200

Sur un site en direct, vous pouvez également utiliser les éléments suivants.

apc.stat 0

Cela empêchera APC de vérifier si le fichier a changé depuis sa dernière compilation, ce qui vous donne une belle augmentation de vitesse. N'oubliez pas de vider votre cache APC lorsque vous modifiez des fichiers PHP.

Ajoutez d'autres pensées. Vous voudrez peut-être augmenter votre taille innodb_buffer_pool_size, 128M peut être un peu faible et même les petits sites peuvent se développer assez rapidement. La variable dicte combien de vos données sont conservées en mémoire.

Magento l'utilise pour toutes ses tables, y compris les tables de journal qui se développent rapidement. Vous voudrez vous assurer de limiter la quantité de ces données que vous conservez. L'exécution de "php shell / log.php --status" à partir de la ligne de commande vous donnera une idée de l'endroit où vous en êtes et si cela vous échappe. Il existe également des options pour nettoyer les tables de journal avec.

2 Go de RAM n'est pas beaucoup de travail, vous devez donc faire attention à l'endroit où vous allouez votre mémoire.

Un cache pleine page + cache plus chaud peut également aider à garder le catalogue et les pages cms de votre site amorcés et rapides. Vous pouvez voir le nôtre ici: http://ecommerce.brimllc.com/full-page-cache-magento.html