Submitted by microniko on
Bonjour,
Je co-gère le site d'une association d'à peu près 200 membres sous Drupal 7. Il y a un forum et des pages avec des articles. Chaque membres a un compte utilisateur et le temps de chargement est une catastrophe. Plus de 10 secondes pour charger une page de forum c'est bien trop long, du coup le site est peu utilisé.
J'ai tenté de mettre en place des systèmes de cache comme APC et memcache mais ça ne change pas grand chose.
Je soupçonne l'architecture de notre site d'être à l'origine de la lenteur. Nous avons même testé un "gros serveur dédié" (4 cœurs, 16 Go de RAM) mais rien n'y fait. Même en augmentant les capacités mémoires de MySQL et PHP !
Pour décrire le site rapidement, il y a pas mal de vues (calendrier d'évènements, carte de localisation des membres avec OpenLayers...), un forum et une gestion assez avancée des permissions avec 22 rôles différents (le tableau de bord indique 2539 permissions utilisées -je suppose que c'est beaucoup) pour le forum et aussi pour certains types de nœuds (et même certains nœuds spécifiquement). Content Access répond tout à fait à nos besoins (basé sur les rôles des utilisateurs), Forum Access également et vu le fonctionnement de l'association, il n'est pas envisageable de diminuer le nombre de rôle.
Auriez-vous des pistes pour l'amélioration des performances ?
Merci beaucoup.
Bonjour,
Permalien Soumis par Damien LAGUERRE le 12 Avril, 2013 - 12:35
Bonjour,
Normalement si APC est bien configuré vous devriez avoir un gain direct.
Après avez vous bien configuré mysql ?
quelle valeur avez vous à "realpath_cache_size"
Combien de table et combien sont en cache ?
Avec un serveur bien configuré vous ne devriez pas être au delà de 300ms.
Pouvez vous nous montrer un phpinfo(); pour que l'on puisse analyser votre configuration ?
Je vais me re-pencher vers
Permalien Soumis par microniko le 12 Avril, 2013 - 13:33
Je vais me re-pencher vers APC alors. Je l'avais peut-être mal configuré.
La valeur de realpath_cache_size est à 16 K (valeur par défaut). J'ai créé un phpinfo();pour voir.
Concernant MySQL, j'ai modifié quelques paramètres :
max_allowed_packet = 128Mtmp_table_size = 64M
max_heap_table_size = 64M
query_cache_limit = 64M
query_cache_size = 64M
Le module Devel me donne quelques infos, la plupart des requètes qui mettent plus de 5 ms sont plusieurs fois (plus de 10) les mêmes :
49.94 ms - lock_acquireINSERT INTO drupal_semaphore (name, value, expire) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2)
et :
49.58 ms - lock_releaseDELETE FROM drupal_semaphore WHERE (name = :db_condition_placeholder_0) AND (value = :db_condition_placeholder_1)
Je ne comprend pas la question « Combien de table et combien sont en cache ? »...
Merci !
Bonjour,
Permalien Soumis par Damien LAGUERRE le 12 Avril, 2013 - 14:23
Bonjour,
Alors passez realpath_cache_size à 1M.
La différence va se faire sentir.
Sinon je vous parle du nombre de table que gère mysql pour configurer au mieux table_cache.
Je pense que votre problème viens vraiment de votre configuration mysql. Drupal est très gourmand en requête SQL.
Bonjour,
Permalien Soumis par microniko le 13 Avril, 2013 - 12:51
Bonjour,
Voici le bilan de quelques tests...
Nous avons remis APC en place. Ça a améliorer sensiblement les choses. En gros, on a gagné 2 secondes d'éxécution mais on est toujours aux alentours de 4 secondes ce qui nous semble beaucoup trop.
Le nombre de tables que gère MySQL. Il y a 278 tables dans la base de données de Drupal et les tables de cache sont les suivantes :
Soit 20 tables.
J'ai également augmenté (je pense) les paramètres MySQL :
[mysqld]max_allowed_packet = 2048M
tmp_table_size = 1024M
max_heap_table_size = 1024M
query_cache_limit = 1024M
query_cache_type = ON
query_cache_size = 1024M
Merci pour votre aide !
Bonjour,
Permalien Soumis par Damien LAGUERRE le 13 Avril, 2013 - 13:09
Bonjour,
APC :
Avez-vous installé et bien configuré le module apc de drupal ? (http://drupal.org/project/apc)
Il faut rajouter quelques variables à votre settings.php comme indiqué dans la documentation du module : http://drupalcode.org/project/apc.git/blob_plain/refs/heads/7.x-1.x:/README.txt
Je vous conseil aussi cet article sur l'optimisation d'APC. http://gregrickaby.com/2012/01/the-perfect-apc-configuration.html
MySQL :
Attention cependant à l’augmentation des valeurs de la configuration de MySQL. Une valeur trop importante peux causer plus de dégât.
Je vous conseil d'installer un script comme celui-ci pour tester votre configuration http://www.ubuntugeek.com/mysqltuner-check-your-mysql-server-performance.html
Avez-vous modifié realpath_cache_size ?
Il faut pour que les résultats soit intéressant que le serveur MySQL fonctionne au moins depuis deux jours.
Bonjour,
Permalien Soumis par microniko le 13 Avril, 2013 - 17:56
Bonjour,
Pour APC
Oui, le module APC est bien configuré, la configuration a été faite en suivant la documentation du module.
Nous avons essayé les optimisations proposé dans le lien que vous indiquez mais en laissant les configurations par défaut pour APC (avec seulement apc.enabled=1), ça semble être encore mieux. Nous allons laisser APC tourner comme ça et voir.
MySQL
Nous avons suivi les recommandations de MySQLtunner mais les performances étaient moins bonnes. J'ai remis des valeurs élevées :
[mysqld]# Paramètres qui semble plus efficace
max_allowed_packet = 1024M
tmp_table_size = 1024M
max_heap_table_size = 1024M
query_cache_limit = 1024M
query_cache_type = 1
query_cache_size = 1024M
innodb_buffer_pool_size = 256M
table_cache = 512K
# Paramètres conseillés par mysqltuner
#max_allowed_packet = 256M
#tmp_table_size = 64M
#max_heap_table_size = 64M
#query_cache_limit = 64M
#query_cache_type = 1
#query_cache_size = 64M
#innodb_buffer_pool_size = 256M
#table_cache = 128M
Nous relancerons MySQLTunner dans quelques jours pour voir si les propositions changent.
PHP
Oui, nous avons bien modifier la variable realpath_cache_size = 1M.
Bonjour,
Permalien Soumis par Damien LAGUERRE le 13 Avril, 2013 - 19:05
Bonjour,
Pour APC il faut tenir compte des stats pour bien configurer le cache d'opcode. Sans quoi APC va ralentir le serveur.
Voici ce que vous devriez avoir : http://gregrickaby.com/apc.php
Sans rentrer dans les détails, la valeur là plus importante à contrôler est Misses, elle ne devrait jamais dépasser 1%.
Je trouve votre configuration MySQL déséquilibré et j'espère que votre serveur est en mesure de tenir une telle configuration.
Sinon attention à la valeur table_cache on parle ici d'un nombre de table et non pas d'un espace.
http://dev.mysql.com/doc/refman/5.0/fr/table-cache.html
La valeur de Misses est 0,3 %
Permalien Soumis par microniko le 15 Avril, 2013 - 21:51
La valeur de Misses est 0,3 %. Avec seulement :
apc.shm_segments=1apc.shm_size=128
Nous avons un « gros serveur », il devrait être en mesure de tenir la configuration. Cependant, je suis preneur de conseil pour l'ajustement des valeurs. Inutile de gaspiller des ressources système !
Aujourd'hui, le seul conseil de MySQLTunner (à part de lancer un OPTIMIZE TABLE) est d'ajuster la valeur de table_cache (> 431) j'ai donc mis 450.
J'attends quelques jours avant de redémarrer MySQL pour voir ce que dira MySQLTunner demain.