Bonjour à vous, grands programmeurs!
 
Travaillant en ce moment sur un site qui me permet de continuer mon apprentissage en php/mysql et ajax, j'ai une question qui me turlupine. Ce site devrait être lancé d'ici quelques semaines et la question que je me pose n'est peut-être pas encore d'actualité. Mais ma question se pose sur les contraintes que peut poser un grand nombre de visiteurs pour le site et le CMS que je suis en train de coder, en particulier sur la base de donnée.  
 
J'imagine qu'il y a des risques quand les gens postent trop en même temps. Comment faire pour prévenir de ces risques? On lit très souvent que telle ou telle opération est à éviter parce qu'elle consomme beaucoup de ressource serveur. Mais pour quantifier cela concrètement c'est pas facile...
 
Enfin bon, quelles sont les démarches et les bons réflexes à avoir?
 
Merci à tout ceux qui me liront (et encore mieux à ce qui me répondront!)

1/ pas d'optimisation avant d'avoir mesuré
2/ pas d'optimisation avant d'avoir mesuré
3/ pas d'optimisation avant d'avoir mesuré
4/ pas d'optimisation avant d'avoir mesuré
5/ optimiser les requetes mesurées comme lourde et fréquente
5/ utiliser des caches mémoires , type apc , sur les donnés utilisées fréquemment
6/ utiliser de caches pour le rendu  
 
.....
 
185634876459/ optimiser les opération peu courantes et peu couteuses

bien bien, c'est à peu près ce que j'avais en tête

D'autres avis?

Il faut avoir la loi de Pareto en tête : 80% des demandes/requêtes se feront sur 20% des fonctionnalités de ton site. Donc optimise un max ces 20% et mesure les effets de bord pour le reste...

D'accord, je prends.  
 
Pour mesurer mes requêtes, vous privilégiez certaines techniques? Ca fait partie des choses à apprendre pour moi..

si t'es sur un serveur dédié, tu peux essayer mysql_tune.sh ou mysql_primer.sh
 
Après faut aussi optimiser ton code source, en vrac :
- déclarer et typer ses variables
- pas de SELECT *
- pas de echo "$var"
- limiter les cas de tests sur l'égalité triple === ou !== (càd si la fonction PHP ne renvoie qu'un booléen, c'est pas la peine de tester le type en plus de la valeur, mais cette remarque est fausse si la fonction renvoie un boléen en cas d'échec et un numérique  ou un texte ou un pointeur en cas de réussite)
- faire toutes les opérations possibles dans MySQL pour éviter un 2nd traitement par PHP
- mettre des ID numériques auto incrémentés plutôt que des primary keys sur des char/varchar
- typer ses champs SQL (date pour une date, int pour un entier, float pour un prix)
- construire intelligemment ses index et ses clés
- limiter le nb de hits (requêtes HTTP) en utilisant des images "sprites" (ce qui n'a aucun rapport avec la boisson)
 
 
après dans les détails "annexes", je ne sais pas si ceux-ci peuvent influencer, mais d'autres me complèteront ou réfuteront :
 
- utiliser un singleton pour la connexion mysql
- compression gzip, p-ê à ne réserver que pour les gros contenus, pour les 80% dont je parlais, préférer un cache

A voir selon les cas, certaines opérations complexes seraient plus lente avec MYSQL qu'avec un traitement PHP équivalent.
 
Dans le même genre que les "sprites", il y a tout ce qui est indiqué sur le blog "performance web" ( http://performance.survol.fr/ ). Ca couvre large mais uniquement si ça a une influence sur le navigateur, les temps de transfert ou la récupération d'une page/ d'un fichier. N'y cherchez pas des optimisations de bases de données, c'est pas son domaine.
 
Le gzip, en règle générale, c'est valable même pour les petits fichiers (enfin bon, si c'est juste 10 octets, laissez tomber ).

lien intéressant, merci beaucoup!
Et globalement merci pour tous les conseils que j'écoute de manière consciencieuses

Le bazooka, c'est :
 
- Un serveur web Apache bien configuré : Les rewrites rules dans ton vhost et non dans un fichier htaccess, des rewrites rules basées sur un pattern avec id et non n rewrites rules avec une chaine de caractère (vécu : une rewrite par ville de France = plantage assuré), un nombre de rewrites rules volontairement limité (100-200 max). Gain : vital pour ne pas écrouler ton site comme un pauv' merde .
 
- une architecture avec du cache mémoire distribué type Memcached, ou à minima du cache fichier. Les résultats de ta requête / ton html / css / js (selon ce que tu souhaites cacher) sont générés au premier accès. Ensuite, et selon la durée de validité du cache, seul ce cache est servi aux clients. Gain : x5000
 
- Un serveur web NginX pour servir les images. Bien plus perf que Apache pour ce genre de tâche. Gain : x1000
 
- Préparer tes requêtes SQL avec le caractère ?, utiliser un singleton pour t'y connecter, ne pas sélectionner tous tes champs, utiliser des jointures et un moteur de stockage innoDB au lieu de MyISAM.
 
- Plein d'autres optimisations. Télécharge Google Page Speed.

 
+1 memcached, redis etc.
 
Sur le produit sur lequel je bosse, quasiment tous les résultats des requêtes MySQL SELECT passe dans memcached. On pioche dans le cache ce dont on a besoin, et si on ne trouve pas on exécute la requête MySQL correspondante et on range le résultat dans Memcached.
 
Les serveurs Memcached permettent d'avoir un espace mémoire commun à tous les scripts PHP ainsi qu'à plusieurs instances de serveur Apache. (Possibilité de DNS round-robin)

alors j'ai tout bien noté, je remercie tout le monde pour ces precieux conseils! Comme je me forme en autodidacte, ce sont des choses que je prends un certains temps à la fois à assimiler et à apprendre.

Mais au moins, grâce à vous, je suis au taquet pour apprendre correctement ce que je veux apprendre

Bonjour, sujet très intéressant
Memcached sert à mettre en mémoire résultats requêtes, variables, toussa ..
cela est-il plus efficace que stocker dans un fichier ? la mise en place est aisée ?

pour le page speed ils disent tjrs : servez vos images depuis un ndd sans cookies, si tu le fais ça repète : "veuillez diminuer le nb de requetes dns"
d'ailleurs a t-il une grande influence sur le référencement ?? ( si on considère qu'un panneau adsense est contraire à leurs règles .. )

sinon
+1 pour innoDB,myISAM est plus adapté aux recherches de texte

Utiliser un profiler sur ton code PHP pour voir où sont les goulots d'étranglement. Une fois que tu sais où ils sont, soit tu les optimises en PHP, soit (dans les cas extrêmes) tu les écrits en C dans un module à part que tu inclus.

Mais encore une fois, comme dit plus haut : On n'optimise jamais avant d'avoir mesuré.
Suffi d'appliquer déjà certaines règles de bon sens (par exemple l'utilisation de requêtes préparées) pour déjà pas mal avancer. Après toutes les optimisations sur le serveur web (genre quantité de ram, nombre de threads créés,...) et sur la bdd ça se fait à la fin, et en général avec un Sysadmin + DBA expert à côté

aller, là je commence à être bien largué
Il va y avoir du googlage dans les chaumières huhu

le profiling, est la clé
perso si le temps de calcul > 120ms en fin de page, cela genère un fichier déterminant là où ça pédale dans la semoule ( essentiellement des requêtes sql avec trop de résultats )

Une chose à savoir sur le parallélisme des requêtes :
- quand une table est en lecture, une autre requête en lecture peut être exécutée simultanément
- lorsqu'il y a un accès en écriture/modification, celui-ci doit attendre que les lectures en cours soient finies, et toutes les nouvelles requêtes en lecture sont mises en attente tant que la mise à jour n'a pas été terminée
Donc, une seule requête longue en écriture peut bloquer beaucoup de choses  
 
(à nuancer néanmoins selon le moteur utilisé)
 

Ca n'existe pas déjà dans MySQL, le cache de requêtes  
Ré-exécuter une requête sur des données non modifiées, il renvoie directement le résultat précédent.

Si, select sql_cache champs (est sensiblement plus longue pour le premier appel, ne convient pas aux bases avec bcp d'écriture, mais plus aux "contenus" qui ne varient pas)
dans le my.cnf il y a les options "concurrent_" qui déterminent les priorités lecture/écriture

 
Dans le cas où justement les données bougent beaucoup, le cache MySQL n'aide pas.
 

 
En fait pour faire face à une montée en charge il y a plusieurs techniques :
- l'optimisation : voir les posts au-dessus qui en parle
- la scalability (extensibilité en français dixit Wikipédia)
Il est possible de s'adapter en augmentant les capacités de l'environnement (CPU, RAM, stockage, nombres de machine).
Il est ainsi possible de faire face à de grosses montées en charge sans forcément avoir optimisé.
Il faut certes que l'application PHP soit conçu d'une manière, mais une fois que c'est en place, généralement on y touche plus.
 
Document intéressant à lire : http://pwet.fr/blog/performances_e [...] calability

je ne penses pas qu'il faille opposer ces deux approches  
le but est d'optimiser l'experience de l'utilisateur en jouant sur les temps de génération, de réseau , et de rendu

par exemple, mes dernières mesures sur mon système de cache :
=> 22ms pour lire le fichier de cache, puis faire "exit"
cela est-il long ?
Je viens à me demander s'il faut favoriser certain disque pour son serveur ( pour mon prochain )