Augmenter les perfs de votre site web

[thierry8]

.
Je me permets de rajouter un point :

vous disiez qu'il fallait ajouter un index aux champs qui sont souvent utilisés avec une condition where, ou autre..dans la plupart des cas ce n'est pas faut, mais il faut savoir que dans le cas ou il y a plus d'accès en écriture les index ralentissent énormément. Ces cas sont plus rare mais peuvent éxister.

[poppyto]

Pas faux, mais ça arrive très rarement sur un site Internet

[yanhl]

Cas rare effectivement, mais qui peut arriver avec certains logiciels de statistiques. A ce propos, réfléchissez avant d'installer un tel script qui fait au minimum un accès base ou disque, au pire un appel de page + une connexion à la base + plusieurs requêtes pour chaque page consultée par vos visiteurs.

Avis personnel : il vaut mieux utiliser un service externe plus qui offre souvent plus d'infos (Google analytics vs phpMyVisites, au hasard) qui ne vous prendra aucune ressource, ou un analyseur de fichiers logs si les infos dispos par Javascript uniquement ne vous intéressent pas (résolution, nb de couleurs, flash installé...).

[poppyto]

Je ne suis pas entièrement d'accord. Les outils de stats sont très bien pour établir une moyenne de ce qui se passe sur son site.

Si on veut en savoir plus sur un point spécial, il vaut mieux écrire ses propres scripts.

Je m'en sers pour les HTTP_REFERER qui sont largement filtrés dans les outils de statistiques.

[spidetra]

En terme de perf, le SGBD est souvent un goulot d'étranglement. Il n'est pas toujours possible d'intervenir directement sur la configuration du SGBD, sauf pour ceux qui ont leur propre serveur dédié.

1. Réfléchissez bien à votre modèle de donnée
Les erreurs de conception de votre modèle de donnée seront lourdes de conséquences en terme de performances plus tard.
Vous devrez faire des efforts d'optimisation considérables pour compenser les erreurs à ce niveau.

2. Ne mettez jamais de requête dans une boucle
Mettre une requête SQL dans une boucle est un bon moyen de mettre à genou votre serveur SQL.
Il existe certainement une meilleure solution réduisant la charge serveur.
Cette solution vous obligera certainement à ré-écrire votre requête.

3. N'hésitez pas à réfléchir et à tester vos requêtes avant de développer.
- Cela vous permettra de débusquer assez tôt des erreurs de conception
- Vous pourrez optimiser vos index ( explain en mysql )

C'est au niveau SQL que vous pouvez avoir des gains de performances important. Ces gains seront facile à obtenir si la conception initiale est bonne.

[yanhl]

Je ne suis pas entièrement d'accord. Les outils de stats sont très bien pour établir une moyenne de ce qui se passe sur son site.

Si on veut en savoir plus sur un point spécial, il vaut mieux écrire ses propres scripts.

Je m'en sers pour les HTTP_REFERER qui sont largement filtrés dans les outils de statistiques.

A mon avis, ça ne rentre plus dans le cadre de l'optimisation des perfs, ce dont tu parles concerne le fonctionnel/marketing.

Si on garde une optique "optimisation pure", on évitera de faire les choses deux fois.
Puisqu'on est légalement obligés de conserver des logs, il vaut mieux se prendre un bon analyseur de logs brutes type Webtrends, ou bien dans ton cas faire des scripts pour parser les logs apache, les mettre en base de donnée et les analyser... mais offline.

[yakipa]

Utilisation des indexs
N'oubliez pas de placer des indexs sur vos champs sur lesquels vous faites vos SELECT. C'est très simple à effectuer (vous pouvez le faire via PHPMyAdmin) et ça accélère vraiment BEAUCOUP les recherches en base.

Concretement on fais comment dans phpmyadmin ?
Il faut le faire généralement sur le champ sur lequel on fait le WHERE ?

[lothar]

Utilisation des indexs
N'oubliez pas de placer des indexs sur vos champs sur lesquels vous faites vos SELECT. C'est très simple à effectuer (vous pouvez le faire via PHPMyAdmin) et ça accélère vraiment BEAUCOUP les recherches en base.

Concretement on fais comment dans phpmyadmin ?
Il faut le faire généralement sur le champ sur lequel on fait le WHERE ?

Si mes souvenirs sont bons il te suffit de cocher le champ sur lequel tu veux créer un index.

[yakipa]

Merci , visiblement tous mes ID (clé primaire) sont en index

par contre ca je comprend pas trop :
Config d'Apache
Si comme moi vous n'en voyez pas l'intérêt, je vous conseille de ne pas logger tous les appels serveurs. Personnelement, le ne logge pas les appels aux images et feuilles de styles, ça évite d'avoir des fichiers énormes et limite les accès disques.


C'est a dire ? en gros desactiver les logs ?

[spidetra]

Merci , visiblement tous mes ID (clé primaire) sont en index

C'est normal. Les PK, sont toujours des index. Il faut aussi regarder les autres colonnes

[yanhl]

yakipa> exemple :

SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.jpg image-request
SetEnvIf Request_URI \.png image-request
SetEnvIf Request_URI \.css image-request
SetEnvIf Request_URI \.js image-request
CustomLog /path_de_ton_log/access.log combined env=!image-request

[cecileB2K]

Config d'Apache
Evitez également l'activation des htaccess placés dans les répertoires et placez tout dans le fichier de conf de votre site, afin d'éviter beaucoup d'accès disque inutiles.

Ca c'est un truc que je ne connaissais pas, bon tuyau en effet, la conf et autre rewrite en tout genre sont alors chargé en mémoire une bonne fois pour toute au demarrage d'Apache.
...pas oublier de le redemarrer par contre si l'on fait une modif dans httpd.conf

Pour en revenir a MySQL et aux index en particulier, pour avoir longuement "étudié" le sujet...les index (entre autre) ont un impact non négligeable sur les perfs MySQL ... mais ça va aussi bien dans un sens que dans l'autre.
En clair il vaut mieux ne pas avoir d'index du tout que des index mal placés, sinon c'est pire que le mal.

EXPLAIN est indispensable, le plus dur est d'interpréter le résultat.

J'ai beaucoup appris grace a une personne (Daniel) webmaster d'un site malheureusement inaccessible depuis déjà qqs jours --> http://codenode.com/ ... je n'ai jamais trouvé d'équivalent, ce site était une véritable mine d'or. *

Au titre des autres améliorations (toutefois minimes // aux index) le type de champ est important et afin d'éviter le trasntypage, vérifier que les champs identiques (un ID par exemple) soit enregistré dans un champ identique.

* j'ai retrouvé (merci le cache de Google) trois articles interessants et qui m'ont été très utile.

Optimizing Slow Queries Case 1: Basic Indexes
Optimizing Slow Queries Case 2: Table Design and Index Details
Optimizing Slow Queries Case 3: ORDER BY With LIMIT and ANALYZE

De la bonne ET saine lecture

[nza2k]

Evitez également l'activation des htaccess placés dans les répertoires et placez tout dans le fichier de conf de votre site, afin d'éviter beaucoup d'accès disque inutiles.

Salut et merci beaucoup pour ces précieux conseils Yanhl.

Etant donné que mon site est hébergé en mutualisé, je n'ai pas d'autres choix pr configurer des régles de reécritures (par exemple) que de placer des fichiers .htaccess dans différents répertoires.
Sur ce point particulier, j'aimerais plus de précisions s'il te plaît :

- Dans quelle mesure est-ce pénalisant ? Les temps d'affichage sont allongés de 0.1, 0.5, 1 seconde... ?
- Toutes les pages de mon site (même celle qui ne sont pas "reécrites") sont-elles affectées par ce ralentissement ?
- Est-ce que seuls les premiers affichages d'un repertoire contenant un .htaccess sont ralentis ? Ensuite, les règles du .htacess de ce répertoire sont gardés en mémoire par le serveur un certain temps et il n'y a plus d'accés au disques ?
Si c'est le cas, est-ce que ça voudrait dire que le pis allé serait de centraliser toutes nos règles dans un fichier .htaccess unique placé à la racine du site ?

Par avance, merci à tous ceux qui pourraient m'éclairer

[yanhl]

Je te recommande la doc d'Apache, page sur les htaccess, point "When (not) to use .htaccess files" ( http://httpd.apache.org/docs/trunk/howto/htaccess.html ) qui répond à toutes tes questions, excepté la perte de performance qui est difficilement quantifiable.
Ca dépend de beaucoup de choses : nombre de fichiers dans la page, profondeur dans l'arborescence, cache disque, etc etc.
Mais ça n'est pas de l'ordre de la seconde en tout cas, c'est quasi certain

[nza2k]

Ah ! Merci bien pour ce lien, ça répond effectivement à mes questions (et ce, de façon compréhensible, ce qui n'est pas toujours le cas avec les docs techniques).


A+