Bonjour,
Merci Cédric pour ces conseils, c'est un retour d'expérience précieux.
Je suis passé à peu près par les mêmes phases d'optimisation des squelettes (il ne me reste qu'à trouver comment optimiser les boucles générées par polyhiérarchie qui n'utilisent pas les index, mais l il va falloir que je mette les mains dans le cambouis et je n'ai pas encore eu le temps), avec en plus une grosse réflexion sur le découpage, les inclusions statiques/dyn, et les caches.
A ce jour mon var_profile est assez stable et satisfaisant, les pages les plus gourmandes ne dépassent pas les 2 secondes de calcul SQL
ouch, c'est vraiment beaucoup.
J'essaye toujours de ne pas dépasser le quart de seconde.
Au delà, il faut chercher le problème, car dans la pratique cela laisse largement le temps de récupérer toutes les informations nécessaires à construire une page.
et leur cache est assez long (je descendrai certainement en dessous de la seconde une fois la polyhiérarchie optimisée car je suis malheureusement obligé de faire appel assez intensivement à branche_complete en raison de contraintes éditoriales complexes).
Je suis d'accord que polyhierarchie a un cout, et pour le moment je n'ai pas trouvé d'optimisation simple.
Mais même avec, sur un site comme cuisine-libre, je reste dans la cible du quart de seconde, et dans tous les cas largement sous la demi-seconde.
Au delà, on peut faire tout ce qu'on veut, 2 secondes de calcul c'est vraiment long (en plus cela ne concerne que le sql, il faut ajouter l'execution du php).
Le cache a plein de vertus, et permet de lisser la charge, et de répondre à des pics de visites, mais in fine, lorsqu'une page doit être mise à jour, ce temps de calcul viendra toujours charger le serveur.
Par contre, si le var_profile est assez stable, les valeurs temporelles renvoyées par var_mode=debug pour la compilation des squelettes sont assez aléatoires (elles oscillent, pour un même squelette, entre quelques millisecondes et quelques dizaines de secondes sans raison apparente quand on le teste plusieurs fois d'affilée).
Pour la compression CSS / JS, elle est en place bien que le couteau suisse (impossible de me passer de certaines lames)
c'est un choix. Impossible sûrement pas. Si tu as fais un comparatif avec et sans le couteau et que tu n'as pas vu d'impact sur la perf de ton site et la charge de ton serveur, ça va. Sinon, tu sais ou gratter.
la supporte mal : certains media type à corriger pour "all" (j'y travaille), et le fait que les url vers ses js / css sont en absolu en utilisant URL_SITE_SPIP, à cause de leur utilisation à la fois dans le public et le privé (là c'est un peu plus compliqué, je ne sais pas vraiment comment corriger ça sans tout péter).
Sur le front de la config serveur :
- gzip est activé sur tout le serveur et testé (il a fallu rajouter un mime-type "application/javascript" car la config par défaut ne gérait que "text/javascript", vu la taille de jquery ça faisait mal côté BP !)
- l'écran de sécurité est up, je n'ai pas vu de différence flagrante
Je vais de ce pas me pencher sur expire, Xcache et la mémoire virtuelle.
Je pense quand-même que j'ai un souci soit au niveau de php, soit au niveau des MaxClients / StartServers / MinSpareServers / MaxSpareServers / MaxRequestsPerChild comme le disait XDjuj, parce que les temps de réaction du serveur pour l'utilisateur sont vraiment longs (un audit de connectivité a donné un temps moyen de plus de 3s avant de recevoir le premier octet) alors que la courbe de charge processeur est plate (< 5%) et la ram n'est pas saturée (aucune utilisation du scratch).
Ben oui, mais si il faut 2s de SQL + le calcul du php + le transit, c'est pas très étonnant.
Il faut regarder le ping pour la connectivité pure.
Ensuite tu peux faire un test sur un fichier statique (img, js, css) pour voir apache tout seul, aussi bien en terme de temps de réponse initial+capacité.
Enfin seulement il faut regarder ce que donne un hit php, puis un hit SPIP. Cela te permet de voir quelle couche rame.
Par ailleurs, il y a un réglage par défaut très mauvais dans apache, qui est le
KeepAlive On
KeepAliveTimeout 15
Si tu as cela, en première approche il vaut mieux le passer à Off. Ensuite, pour affiner le temps de réponse vu du client on peut le garder à On, mais avec un timeout de l'ordre d'1s à 2s maxi, ce qui se traduit dans tous les cas par une augmentation de la charge serveur (du fait des process qui restent ouverts en attendant une éventuelle suite).
Tout ceci semble confirmé par le test qu'on est en train de conduire : on a déplacé le serveur SQL sur un serveur alternatif (même baie) avec quasiment aucune amélioration sur le temps de réactivité client.
Ah, plutôt mauvais choix je pense. Avoir le SQL sur le même serveur qu'apache est toujours plus rapide.
Je vais demander à l'administrateur de la machine de me transmettre les valeurs de config du serveur (je ne suis que webmestre / développeur, mes connaissances en admin serveur sont théoriques et limitées), histoire de voir si elles ne sont pas aberrantes.
Côté plugins spip, je pense tester assez vite cache-cool (j'attends que vous le stabilisiez encore un tout petit peu, il est jeune, mais chapeau pour la vitesse de mise au point ! 
et fastcache également pour mes pages les plus sollicitées, mais comme les lenteurs frappent aussi les pages lues depuis le cache...
Oui, ces plugins sont bien "en plus" quand on a optimisé tout le reste et qu'on est bien afuté. Ils permettent alors de gagner encore un peu (voire beaucoup). Mais si à la base il y a des gros freins, ils ne feront pas de miracle.
Cédric
et fastcache également pour mes pages les plus sollicitées, mais comme les lenteurs frappent aussi les pages lues depuis le cache...