Optimisation site

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

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.

Version de Drupal : 

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 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      = 128M 
tmp_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_acquire
INSERT INTO drupal_semaphore (name, value, expire) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2)

et :

49.58 ms - lock_release
DELETE 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,

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,

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 :

  • Structure drupal_cache
  • Structure drupal_cache_block
  • Structure drupal_cache_bootstrap
  • Structure drupal_cache_field
  • Structure drupal_cache_filter
  • Structure drupal_cache_form
  • Structure drupal_cache_image
  • Structure drupal_cache_l10n_update
  • Structure drupal_cache_libraries
  • Structure drupal_cache_menu
  • Structure drupal_cache_metatag
  • Structure drupal_cache_page
  • Structure drupal_cache_path
  • Structure drupal_cache_rules
  • Structure drupal_cache_token
  • Structure drupal_cache_update
  • Structure drupal_cache_views
  • Structure drupal_cache_views_data
  • Structure drupal_ctools_css_cache
  • Structure drupal_ctools_object_cache

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,

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,

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,

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 %. Avec seulement :

apc.shm_segments=1
apc.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.