Non non, c'est le GET de la requête apache qui se traine du bout... En gros, le serveur met 3 plombes avant de répondre quoi que ce soit...
Justement, c'est peut-être dû à la base, y'a un paquet de trucs qui peuvent faire traîner le GET HTTP. Notamment le fait de mouliner pendant des heures sur une requête SQL
Apache en lui-même est quand même super réactif, c'est rare qu'un GET traîne parce que Apache en chie, à part quand on commence à taper dans les limites (du genre gros bench avec plusieurs dizaines de milliers de connexions simultanées renouvelées en permanence, et encore même sur un serveur modeste on arrive aux limites de la couche réseau plus qu'aux limites d'Apache, avec une saturation du nombre de sockets et des pertes de paquets). Il se peut aussi qu'il y ait des pertes de perfs assez violentes quand on fait une montée en charge extrêmement rapide (j'ai fait des tests à +5000-10000 connexions en quelques secondes), parce qu'Apache a besoin d'un process (ou thread) par connexion, et il y a beaucoup d'inertie à la montée de charge (genre +- quelques dizaines de process par seconde). Dans tous les cas, on est loin de l'activité typique de ce forum
Si tu veux, on peut essayer d'indexer la base ce weekend. Dans tous les cas ça peut pas faire de mal
Tu gères le serveur directement ou c'est une bête mutualisation sans accès à la console ? Parce que si on peut jouer avec le httpd.conf, y'a pas mal de petites modifs qui devraient aider Apache à tenir plus facilement le coup (genre monter le nombre mini de process qui tournent en parallèle histoire de maximiser le nombre de slots dispo même en cas de faible activité, augmenter le nombre de process max, jouer avec limits.conf...).
Ca serait intéressant d'observer la charge du serveur sur une période assez étendue pour voir ce qui se passe (httpd, mysqld, sockets, load average...)
![[ NES Pas ? ]](http://jenesuis.net/forum/Themes/classic/images/smflogo.gif)
