Discussion :

[FMaz]

Explication de la situation:
J'étais autrefois sur un serveur mutualisé. Ayant trop de problème de panne du site pour diverses raison, j'ai décidé de passer sous un Serveur Virtuel Privé (VPS).

Depuis le transfert, plusieurs utilisateurs de mon site ce sont plain que certaines pages prennaient un temps fou à charger. Selon les statistique de génération de la page au bas du site, il arrive parfois qu'un page prenne plus de 300 secondes à générer (pire cas: 560 secondes!). Attention, je dis bien GÉNÉRER, et non pas 'chargé sur une connexion lente'.


Recherche du problème:
Le premier truc qui me viend à l'esprit est qu'il y a un problème avec MySQL: certaines requêtes sont probablement très lente considérant qu'il y a une table de 400mb de données. Ayant une fonction qui gère toutes mes requêtes afin d'en tirer des statistiques, je me rend rapidement compte que toutes mes requêtes sont rapides. optimisable peut-être, mais rien qui ne passe proche de justifier une page qui prend 560 secondes à générer: toutes mes requêtes sont traité en moins d'une seconde.

Je me dis alors que peut-etre que MySQL entre en "collision" car il recevrait deux requête en même temps. Je créer donc un système qui Garde en mémoire toutes les requêtes et le temps pour chaqu'une d'elle. À la fin de la page, si le temps de génération de la page dépasse 60 secondes, je recois le rapport par courrier. Rien, je recois des rapports mais toutes les requêtes sont rapides. Le temps est perdu ailleurs.

Je place donc des 'affichage de temps' un peu partout dans mon code. La lenteur proviend de la boucle qui génère la liste des messages.

Je décide donc de retirer tout les ECHO de la boucle et de tout placer le contenu à mettre sur la page dans un buffer. Et de faire:

echo $he_buffer;

après la boucle seulement. La boucle se fait maintenant en un temps éclair mais je continue de recevoir des rapports de page lente par email. Je place donc un affichage de temps avant et après le echo $he_buffer.

$avant = $timer->finish();
echo $he_buffer;
$apres = $timer->finish();

$avant retourne 0.3
$apres retourne des trucs immenses comme 350.424 par exemple.

Donc le echo prend un temps fou à traiter. Il est vrai que $he_buffer contiend parfois jusqu'à 250Kb de texte mais de la à prendre 5 minutes...


Solutions tentées:
- Contacter le support technique de mon fournisseur VPS. Rien de leur coté, ils ont placé le site sur un dual Xeon 3ghz avec 8gb de ram, le problème persiste.
- Remplacer le echo par un print
- Placer des appel à la fonction flush() avant et après le echo
- Monter le paramêtre memory_limit à 20M dans la configuration de PHP
- Re-vérifier le code plusieurs plusieurs fois avec plusieurs personnes différentes. Le code est bon (et fonctionnais bien avant)
- Recompiler Apache et PHP dans le WHM. la version de PHP à été mise à jours (5.1.4).

Avez-vous des pistes (ou mieux, des solutions) ???

[Lorenzo77]

1ere fois que je vois ca
le probleme ne vient pas de ton code, c'est sur, je me demande s'il y a pas un gros probleme avec ton serveur ...

quel est le systeme + version php + serveur ...etc ?


si tu es sur linux, check l'utilisation memoire et processeur au moment de l'echo car ce n'est pas le genre de commande qui est censé consommer meme avec 250Ko de texte.

[FMaz]

PHP Version 5.0.5

Mysql Client API version 4.1.18

Le serveur est sous une distribution CENT OS
Et le VPS ne confère en tout temps 512 mb de ram et 800mhz de CPU.

Mais le support technique a testé tout ca sur un Dual Xeon 3ghz avec 8bg de ram donc sauf s'il existe un fichier de config qui fait que PHP ou Apache n'utiliserait pas plus de X ressource, le système en a suffisament.

Le CPU n'est jamais surchargé.

[FMaz]

Est-ce que ca pourrait être la faute de "Zend"
Car mon fichier de config de PHP est dans un dossier "Zend" j'ai cherché un peu sur le net et j'ai vu que c'était un accélérateur de PHP.

Se pourrait-il que le délais soit une tentative de mise en cache de la part de Zend ? ou de recherche de correspondance.

Enfin, je sais pas trop ce que c'est mais j'ai même réinstallé Apache et PHP via le panel WHM je suis maintenant en PHP 5.1.4 et le problème persiste toujours.


Ho, et je suis très sérieux à propo de ce problème... Si quelqu'un trouve une solution, je suis prêt à offrir une petite récompense monétaire en guise de remerciement... Je suis vraiment à bout de souffle.

[Yogui]

Salut

Avec une BDD de 400 Mio, c'est un vrai serveur privé dédié qu'il te faut (pas virtuel). Cela m'étonne que ton mutualisé t'aie supporté avec ce volume de données !

Bref.

Zend, en soi, ce n'est rien. C'est une entreprise, si tu veux, mais certainement pas un programme.
Zend Engine est le moteur qui compile les scripts PHP.
Zend Optimizer est un accélérateur de code.
Je ne pense pas que le problème vienne de Zend.

En réalité, je ne vois vraiment pas pourquoi cela ne passe pas.
Tu as cerné le problème au echo unique, je vois ? C'est certain ?
Rappelle-toi que PHP ne compte pas le temps d'exécution des includes et autres exécutions externes au scipt courant : une requête SQL n'est pas comptée dans le temps d'exécution de ton script.

[FMaz]

Bah, je sais pas pourquoi il tolérais, mais j'avais droit à 5gb d'espace disque donc 400mb j'étais loin de la limite.

Ca roulais bien en mutualisé


Maintenant, comme le montre mon extrait de code, il n'y a vraiment QUE le echo sur cette ligne, rien d'autre (pas de include, pas de requête SQL)

Tu semble en connaitre un peu plus que moi, tu as une idée ou tu pense être en mesure de trouver d'ou ca proviendrais ?

j'ai installé Zend Optimizer 3.0 sur le server afin d'être certain d'être à jour et qu'il n'y ai pas d'incompatibilité avec la version actuelle de PHP.

[Yogui]

S'il y a un problème, il y a une source au problème. En ce cas, il est toujours possible de déterminer quelle est cette source.
Cela dit, pour parvenir à cette fin, tu m'as donné très peu de moyens.

Essaie d'afficher la longueur de ton buffer (sans afficher le buffer), pour voir. Quelle taille fait-il ?

Autre chose : généralement (par défaut), PHP ne laissera pas un script s'exécuter plus de 30 secondes.
Comment le tien peut-il continuer pendant, euh, 20 minutes sans que PHP s'en rende compte et que tes utilisateurs n'abandonnent ?

Essaie set_time_limit(30); en début de script.

[Lorenzo77]

la seule soluce pour trouver d'ou vient le probleme : os, php ou apache
ca va etre de logger precisement l'utilisation des ressources de la machine : HDD + memoire + processeur ...etc, il faut trouver le thread qui ce met en "pause" ou qui merde ...

tu as qu'elles possibillitées sur ton linux ?

[Yogui]

C'est un VDS : il est root, il peut même réinstaller la distrib' à distance si besoin ^^

[FMaz]

Je suis sous un VPS, donc techniquement j'ai plein contrôle. J'ai un access SSH à la machine en root sur l'os (CENT OS)

Bon, pour la question des utilisateurs moi aussi ca m'étonne. J'imagine que lorsque PHP commence, il va jusqu'au bout même si l'utilisateur à appuyé sur STOP. Mais je n'en sais rien.

J'ai aussi des limites de temps de défini dans la config de PHP et de APACHE et aussi de MySQL, les valeurs pas défaut je crois. Ca aussi c'est un mystère.


Pour des questions de sécurité il y a certaines choses que je ne peux pas offrir en publique mais si vous pensez pouvoir trouver la source du problème, venez me voir sur en privé, je vous donnerais mon MSN et on verra plus en détails...


Sinon pour la question de monitoring, j'ai regardé le TOP et le CPU n'était pas dutout au plafond et il restait de la mémoire disponible sans problème.

Les techniciens de l'hébergeurs essaie aussi de capturer des infos système lorsque le problème surviend mais malheureusement, c'est aléatoire. Donc très dur à tracer.


Personnellement je trouve que ce problème dépasse toute logique...
Note: Zend Optimiser 3.0 n'à rien changé à la situation. Je vais le désactiver complètement, j'ai rien à perdre... (Edit: Aucun changement)

pour le set_time_limit(30);, je vais essayer, mais si ca marche la page ne s'affichera pas correctement, ce qui ne sera pas mieux non ?

Je viend de vérifier dans php info et max_execution_time est bien à 30 local et master.

Edit: Extrait d'un commentaire sur php.net sur la fonction set_time_limit():

Guys! This script runs 100*10 seconds +- few microseconds for circle and output.
But not promissed 30 seconds!!!
set_time_limit sets CPU time! Texted on *NIX.

Le temps CPU... Comme le TOP n'affiche jamais un CPU à 100% pendant que ca se produit, ca explique pourquoi les timeout ne fonctionnent pas s'ils sont basés sur les temps d'utilisation du CPU.

[Yogui]

Non, ça limite bel et bien à 30 secondes (plus ou moins quelques broutilles de millièmes de seconde).
Je ne t'ai proposé cette solution que pour vérifier que le script accepte de s'arrêter quand il le doit.

Avec max_execution_time à 30 (ce qui est la valeur par défaut), je ne comprends pas pourquoi c'est aussi long.
D'où tiens-tu que le script met 20 minutes à s'exécuter ? Je trouve cette information pour le moins douteuse à plusieurs niveaux.

[FMaz]

Le code suivant calcul le temps de génération de la page:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
//#### TIMER POUR CALCULER LE DÉLAIS DE GÉNÉRATION DE LA PAGE
class timer
{
    function start(){
        global $starttime;
        $time = microtime();
        $time = explode( ' ', $time );
        $time = $time[0] + $time[1];
        $starttime = $time;
    }
    function finish(){
        global $starttime;
        $time = microtime();
        $time = explode( ' ', $time );
        $time = $time[0] + $time[1];
        $finishtime = $time;
        $totaltime = round( ( $finishtime - $starttime ), 4 );
        return $totaltime;
    }
}
$timer = new timer;
$timer->start();

Il suffit de faire $timer->start(); pour démarrer le chrono.
Et $timer->finish(); retourne le temps écoulé depuis le début.

j'ai moi-même attendu plus de 2 minutes pour une page et le temps de génération correspondait bien. Ce code proviend d'une source sur, je me souviend plus si c'est du forum SMF ou du site de PHP, ou les deux... mais c'est pas moi ou un tarré qui la inventé...

[FMaz]

Juste pour infomation, j'ai quitté RapidVPS.com et maintenant je n'ai plus aucun problème ...

C'était bel et bien l,hébergeur qui était en faute (Considérant que je n'ai rien modifié sur l'installation de base)

[FMaz]

En fait le problème n'est strictement pas résolu vu que j'ai du CHANGER d'hébergeur, mais bon, je m'y soumet