Discussion :

[no-war]

Bonjour,

J'obtiens un problème de latences, non régulières, aléatoires, plutôt rares, lors de l'accès au portail d'un intranet.
Par latences, j'entends plutôt de requêtes http sans réponses...
Pas d'erreur 404, rien, ça tourne en boucle indéfiniment. On a testé à plus de 5 minutes. On rafraichit la page, hop résultat instantané.
Il n'y a pas d'erreur dans le code. Au niveau ressources serveur, il y a encore de la marge, on n'excède pas 10%..

Le problème n'intervient pas pour tous en même temps, mais arrive à tous les clients.

Cette appli possède son propre nom de domaine, configuré dans le vhost.
Un alias est posé sur phpmyadmin, qui a lui aussi le problème d'ailleurs.

A l'initial lors d'une période de tests, le reverse dns était configuré dans le fichier host de l'os des quelques clients qui y accédaient.
Le problème apparaissait déjà.
Bref le nombre de clients évoluant, j'ai alloué le reverse dns à la box.
Le problème persiste toujours.

Peu importe le nombre d'utilisateur. Comme ça, sans raison, une fois de temps en temps, les requêtes http se perdent dans la nature.

Je pensais vraiment à un problème de reverse à la base mais il semble que ce ne soit pas le cas.
J'ai fait un audit pendant plusieurs jours, en sniffant le réseau sur le serveur ainsi qu'un client.
Il semble que toutes les requêtes atteignent bien le serveur, mais je ne suis pas certain qu'elles atteignent bien le serveur web.
Pas grand chose au niveau des logs, et le problème est difficilement reproductible... J'ai calé un stagiaire à cliquer toute une journée un peu partout et il n'a pas eu de souci....

J'ai pensé à un problème de connexion en simultanée par utilisateur vers le serveur. Par défaut à 2, je l'ai passé à 3 sachant qu'on ne dépasse jamais les 2.
Rien n'y fait.

Alors là je m'interroge. Je n'ai jamais eu ce problème là auparavant.
Un problème matériel au niveau du serveur ?
Je l'ai mal configuré ?
Un problème de version de php, apache ou je ne sais ?
(Je ne sais pas si je poste au bon endroit en passant)

Le serveur :
proc AMD FX 6100
Windows 2008 R2 entreprise x64
Wamp version 2.2 x64
Php version 5.4.3
Apache version 2.4.2
Mysql version 5.5.24

Quelqu'un aurait-il une solution à proposer, ou au moins une idée vers où diriger mes recherches ?

Merci par avance.

[Marc3001]

T'as une base de données derrière ton/tes applis ?
T'as peut-être un souci de connexions non déconnectées sur ta base et du coup un engorgement.

Lors de l'engorgement, le code appli attends que de nouvelles connexions soient possibles pour continuer son traitement et afficher la page.

Ça a donc en général ce genre de symptôme....

[no-war]

Bonjour et merci de la réponse.

Oui il y a des bases.

PDO est utilisé sur toutes les applis, géré grâce à une classe spécifique. Les connexions ne sont pas fermées mais sachant que l'objet est détruit en fin de script, ça devrait être bon non ? Qui plus est, peu importe la lourdeur des scripts (la plupart sont légers).

Le problème est également apparent dans phpmyadmin qui plus est.

Ah mais j'y pense, une précision omise, j'ai fait un test sur un hébergeur mutu pendant quelques jours (en prod à plusieurs dessus), et tout roule nickel.

Je pencherai plus (sans vraiment savoir) vers un problème réseau ou de config du serveur, peut-être de matériel genre la ram ? (Je ne sais pas, pourquoi pas...)

[Vespiras]

Salut,

- Il y a quoi entre ton serveur Web et ton client ? Un , plusieurs switch ?

- Tu as essayé d y accéder depuis une autre machine ? Depuis une machine sur le coeur de réseau ?

- Grâce à la console onglet Réseau d'un Firebug ou d'un analyseur quelconque intégré à un navigateur, tu peux voir les détails de tes GET de transmission dans tes requêtes vers le serveur.

- Regarde également du côté des logs de ton serveur Web pour voir si il ne génère aucun avertissements (apparament tu l'as déjà fait)

- Vérifie aussi si y a un parefeu (iptables, apf ..) ou autre sur la machine serveur et client, ou un antivirus qui ferait du contrôle sur accès en temps réel mal optimisé.

-Surveille ton port 80 sur ton serveur et regarde tes modules activés sur apache, peut-être qu'il y'en a que tu n'utilises pas et qui sont lourds

Si tu ne trouves rien tu peux également activer le module de compression HTTP d'Apache, qui peut faire gagner jusqu'à 75% de perfs !
Dans ce cas regarde du côté de mod_deflate.
Apache permet aussi de régler la mise en cache avec mod_expires et mod_headers. On peut aussi utiliser la mise en cache côté serveur, dans laquelle le contenu le plus souvent affiché est stocké en mémoire, ce qui permet sa prise en charge rapide.Pour finir le module mod_cache pourrait te servir à la mise en cache côté serveur.

Voila bon courage pour trouver la source de ton problème, voici quelques pistes et astuces, je suis en attente de plus de précisions de ta part.

EDIT : Pour le parefeu, désolé j'avais pas lu que tu etait sous Windows. Bon du coup oublie juste iptables et apf sur mon post, merci

[_Mac_]

Pas 36 approches possibles à mon avis : faire des captures réseau depuis un client qui rencontre le problème et le serveur, les 2 au même moment lorsque le problème survient. Hyper facile à faire

Il se peut que le réseau soit en cause, truc très facile à déboguer. Par exemple les requêtes peuvent très bien ne jamais parvenir au serveur. Pour savoir si c'est Apache qui plante, tu peux a priori t'appuyer en toute confiance sur les logs d'Apache : il y aura forcement une trace de la requête entrante dans l'access_log si la requête est parvenue jusqu'à Apache. Donc si tu connais l'IP de la machine qui a fait la requête, la requête (GET, POST, etc.) et l'heure à laquelle il y a eu plantage, tu devrais retrouver des traces dans l'access_log.

Chose à faire absolument si tu soupçonnes des pbs de perf Apache : ajoute le flag %D dans les traces d'accès pour connaitre le temps mis par Apache pour répondre aux requêtes. Si tu vois des temps très longs ponctuellement et au moment des plantages, Apache est en cause. Restera plus qu'à identifier pourquoi mais au moins le problème aura été localisé.

[no-war]

Bonjour et merci de vos réponses.

@Vespiras,
1) Selon le client, il y a un ou plusieurs switch (le réseau est une horreur en passant...)

2) Je ne suis pas sur de comprendre ta question ? Actuellement, une dizaine de machines clientes se connectent sur ce serveur.

3) Je vais voir de ce côté-ci merci. Bien que je l'ai fait en capturant les trames avec wireshark (serveur + 1 client) pendant plusieurs jours.

@_Mac_,
Bien en fait, je l'ai déjà fait. Mais je vais repartir sur une session d'une semaine cette fois, et un peu plus automatisée. J'ai codé un script (js) qui effectue une requête ajax toutes les minutes sur le serveur avec un très long timeout. Si la requête passe, je récupère l'heure du serveur, si elle ne passe pas, le script me génère une erreur. Donc entre une erreur, je devrais avoir 2 dates valident me permettant de situer un peu plus facilement la requête... à raison de 1440 tentatives/jour, sur une semaine, le problème devrait être plus facilement reproductible, et me permettre de voir sur plusieurs erreurs.

Je reviens vers vous une fois que j'en saurai plus.

Et merci encore, vous m'avez appris quelques petites astuces sympa au passage

[no-war]

Bonjour,

Bon et bien le script a tourné une 10aine de jours sans obtenir une seule erreur
Problème difficilement reproductible, je n'en sais pas plus ni ne sais quoi dire de plus....
J'y reviendrai au retour des vacances.

Merci encore