Astuces de Webmaster

Si votre site est lent, il peut y avoir plusieurs raisons :
- ça peut être un problème serveur, un problème de connexion Internet ou une lenteur d’affichage

Pour les problèmes de connexion Internet, on ne peut pas faire grand chose
Pour les problèmes de lenteur d’affichage, les outils Yslow et PageSpeed (en ligne via gtmetrix.com ou couplés à Firebug pour Firefox) vous donneront toutes les informations utiles pour optimiser votre site, la CSS, les images, etc.
On s’intéressera ici à la partie Serveur, les raisons sont souvent parmi les suivantes :
- des requêtes trop lourdes ou trop fréquentes, ou les deux
- des processus (tâches, générations de fichiers) trop longs (parfois à cause des requêtes)
- des serveurs « extérieurs » qui appellent vos scripts/images trop souvent (un gros site qui appelle vos images fera planter votre serveur si vous n’êtes pas dimensionné pour son trafic)

Requêtes trop lourdes

Connectez-vous en ligne de commande (SSH) à votre console MySQL (ou via phpMyAdmin dans l’onglet processus sur l’accueil) et regardez les processus en cours (commande SQL « SHOW FULL PROCESSLIST; »), vous en verrez peut-être des récurrentes, ou des longues. Maintenant, vous savez quoi optimiser.

Si votre processlist est souvent vide ou pleine de « sleep », tout va bien. S’il y a trop de sleep avec une durée trop longue, réduisez votre timeout ou utilisez mysql_connect plutôt que mysql_pconnect. 2mn peut être une durée honnête pour un timeout.

Identifier les scripts consommateurs

Pour identifier les scripts consommateurs, il est intéressant d’utiliser un petit programme : Apachetop (apt-get install apachetop sous debian – comment installer ?)

Pour voir l’état du serveur, il est bon d’utiliser htop (apt-get install htop sous Debian),

Identifier les extérieurs

Pour voir les extérieurs qui appellent vos scripts, rien de tel qu’un bon vieux tail -f /var/log/apache2/error.log (à modifier par votre nom de fichier d’erreur)

Optimiser mySQL :

• Identifiez-vous en root sur le Shell du serveur considéré
• Pour optimiser MySQL, on va s’intéresser principalement au fichier /etc/mysql/my.cnf (généralement ainsi situé, notamment sur les distributions Debian, mais n’hésitez pas à faire un # locate my.cnf pour identifier la localisation de ce fichier et vérifier s’il n’y a pas de doublon)
• nano /etc/mysql/my.cnf (éditons la configuration)


[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K
# pour utiliser moins de mémoire, si on n'utilise pas Berkeley DB on ajoute cette ligne
skip-bdb
# idem si on n'utilise pas InnoDB
skip-innodb
# de la même façon, si on n'utilise pas InnoDB, on peut commenter les lignes suivantes
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# Vous pouvez définir .._buffer_pool_size entre 50 et 80 %
# de la RAM mais attention à ce que l'utilisation globale de RAM par MySQL ne soit pas trop important (à suivre)
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Définissez .._log_file_size à 25% du buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Décommentez la ligne suivante si vous n'êtes pas familier avec SQL
#safe-updates
[isamchk]
key_buffer = 8M
sort_buffer_size = 8M
[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout

Quelques paramètres qui nécessitent attention

query_cache_size

MySQL fournit une fonctionnalité qui peut s’avérer très pratique : un cache de requêtes. Lorsqu’une même requête est exécutée plusieurs fois, et retourne les mêmes résultats à chaque fois, MySQL peut mettre en cache le résultat, ce qui décharge assez le serveur.

key_buffer

La valeur de key_buffer_size est la taille du buffer utilisé pour les index. Plus il y a de mémoire tampon, et plus rapidement la commande SQL se termine et un résultat sera retourné. La règle de base est de régler le key_buffer_size à au moins un quart, mais pas plus de la moitié de la quantité totale de mémoire sur le serveur. Idéalement, il sera assez grand pour contenir tous les index (la taille totale de tous les fichiers .MYI sur le serveur).

table_cache

La valeur par défaut est 64. Chaque fois que MySQL accède à une table, il la place dans le cache. Si le système accède à de nombreuses tables, il est plus efficace d’avoir ces tables dans le cache. MySQL, étant multi-thread, peut exécuter de nombreuses requêtes sur une table au même moment, et chacune de ces requête va ouvrir une connexion avec la table. Examinez la valeur de open_tables aux heures de pointe. Si vous trouvez qu’il reste à la même valeur que la valeur de votre table_cache, puis que le nombre de opened_tables commence à augmenter rapidement, il faut augmenter la taille du table_cache si vous avez suffisamment de mémoire disponible.

sort_buffer

Le sort_buffer est très utile pour accélérer les opérations myisamchk (c’est pourquoi il est défini beaucoup plus haut dans les fichiers de configuration par défaut), mais il peut aussi être utile lors de l’exécution quotidienne un grand nombre de classements (fonctions comme sort(),…).

thread_cache

Si vous avez un serveur surchargé à force de recevoir un grand nombre de connexions rapides, définissez votre thread_cache suffisamment haut pour que la valeur threads_created de SHOW STATUS (commande SQL) cesse d’augmenter. Cela devrait décharger un peu le CPU.

Autres optimisations MySQL

Bien souvent, c’est sur les jointures que se jouent les lenteurs. Utilisez les jointures à bon escient, vérifiez que pour chaque clé utilisée dans les jointures, il existe bien un index sur ce champ clé, sinon créez-le tout de suite et ça fera une grande différence.

Les chiffres pèsent moins lourd dans les index que les lettres, par conséquent, préférez les clés numériques pour vos jointures de grosses tables pour éviter de trop surcharger vos index.

Apache

Le principal problème avec Apache est la quantité de RAM qu’il utilise. Nous allons voir comment baisser la quantité de RAM utilisée par Apache.

• Charger moins de modules
• Faire moins de demandes simultanées
• Recycler les processus Apache
• Utiliser les KeepAlive, mais pas pour trop longtemps
• Réduire vos timeout
• Créer moins de logs
• ne pas résoudre pas les Hostname
• N’utilisez pas les .htaccess

A lire sur Alsacreations.com : Google introduit le WebP, un nouveau format d’image et en anglais sur http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html

A noter :
- Les JPG + GIF constituent 65% du poids des pages web
- des gains entre 10 et 60% par rapport à JPG !
- Galerie de démonstration de leurs performances : http://code.google.com/intl/fr/speed/webp/gallery.html

Je viens de tomber sur un petit recueil d’astuces pour optimiser ses requêtes et sa base de données MySQL que j’aimerais partager avec vous.

Tout est ici : http://www.lephpfacile.com/manuel-mysql/mysql-optimization.php#tips

- vérifier les index / créés vs qui devraient exister
- types de tables (MyISAM,…)
- éviter les varchar et blob pour ce qui est régulièrement modifié
- pas forcément utile de scinder les grosses tables en plus petites
-…

Une petite check-list à se faire de temps en temps !

Fonction de MySQL injustement ignorée, FROM_UNIXTIME nous permet d’insérer en base un temps UNIX, et permet une sortie de date au format souhaité :

Source : http://dev.mysql.com/doc/refman/5.0/fr/date-and-time-functions.html

FROM_UNIXTIME(unix_timestamp)

Retourne une représentation de l’argument unix_timestamp sous la forme ‘YYYY-MM-DD HH:MM:SS’ ou YYYYMMDDHHMMSS, suivant si la fonction est utilisé dans un contexte numérique ou de chaîne.

mysql> SELECT FROM_UNIXTIME(875996580);
-> ’1997-10-04 22:23:00′
mysql> SELECT FROM_UNIXTIME(875996580) + 0;
-> 19971004222300

Si format est donné, le résultat est formaté en fonction de la chaîne format. format peut contenir les mêmes options de format que celles utilisées par DATE_FORMAT() :

mysql> SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(),
-> ‘%Y %D %M %h:%i:%s %x’);
-> ’2003 6th August 06:22:58 2003′

On en a tous rêvé en secret, on l’avait à peu près découvert en regardant les sources Javascript de Google Maps, il faut maintenant se rendre à l’évidence, on ne peut pas se passer de Minify, un projet déposé sur Google Code.

Vous qui rêviez de rassembler tous vos scripts JQuery en un seul fichier..

http://code.google.com/p/minify/

L’idée ? transformer ça :

<script type= »text/javascript » src= »/_lib/_action/montre2.js »></script>
<script type= »text/javascript » src= »/javascript/prototype.js »></script>
<script type= »text/javascript » src= »/javascript/scriptaculous.js »></script>
<script type= »text/javascript » src= »/javascript/jscalendar/calendar.js »></script>
<script type= »text/javascript » src= »/javascript/jscalendar/lang/calendar-fr.js »></script>

<script type= »text/javascript » src= »/javascript/jscalendar/calendar-setup.js »></script>
<script type= »text/javascript » src= »/javascript/jquery-1.2.3.js »></script>
<script type= »text/javascript » src= »/javascript/jquery.form.js »></script>
<script type= »text/javascript » src= »/javascript/ficheProduit.js »></script>
<script type= »text/javascript » src= »/javascript/resa.js »></script>

en ça :

<script type= »text/javascript » src= »/min/?f=javascript/jquery-1.2.6.min.js,javascript/jquery.scrollTo.js,javascript/player/carousel_behavior.js,javascript/jquery.hoverIntent.min.js,javascript/superfish.js,javascript/jquery.bgiframe.min.js,javascript/jquery.reflect.js,javascript/jquery.form.js »></script>

ce petit bout de code PHP rassemble tous les scripts en un seul, retire les espaces qui ne servent à rien, ce qui compresse un petit peu le tout et vous met ça à disposition.

L’idée c’est qu’au lieu d’une dizaine de requête, vous n’en avez plus qu’une, ce qui allège considérablement les échanges et les temps de téléchargement..

Il suffit d’ailleurs de voir leur exemple : 98KBytes au départ, 29KBytes à l’arrivée.. et moins de questions / réponses entre le navigateur et le serveur.

Et ça marche aussi avec les fichiers CSS

Pour les perfectionnistes, on a là une bonne bible de tout ce qu’on peut faire pour optimiser le chargement des pages : http://developer.yahoo.com/performance/rules.html

Qu’attendez-vous ?

Une page qui m’a servi pas plus tard qu’aujourd’hui, et dont je recommande la (re-)lecture à tous tant elle est pratique :
http://www.vulgarisation-informatique.com/optimiser-mysql.php

L’idée est d’aller chercher les requêtes les plus lourdes que vous avez (si vous avez un serveur dédié, allez fouiller dans le fichier slow-query.log qui enregistre toutes les requêtes durant plus de 5 secondes), de faire un « EXPLAIN [votre requête] » et point par point de voir où il manque des index,… de colmater les brèches en quelque sorte..

Bonne lecture,

Je vous invite à lire cette documentation qui permet d’optimiser les requêtes complexes pour des sites à fort volume :

http://www.ecoms.fr/cours/sgbdoptimisation.pdf [PDF]