Voilà, j'ai un problème avec mon script hbergé chez free.
J'ai eu droit ce soir au message "Fatal error: Maximum execution time exceeded in your script on line 1" depuis à peu près miniut trente ce matin.
 
Je me demandais si d'autre aurait eu le même problème que moi. Ca semble être du à une limitation mise en service assez récemment chez free.
 
Merci de bien vouloir me dire ce que je peux faire contre ce problème là.

Heu t'as quoi en line 1 : while( 1 ) {} ? ? ?

Quel que soit le fichier, la lign 1, c'est ça :
 
<?

Ou bien çà :
 
<? while(1) {} ?>
 
Bon je rigole, j'ai pas de PB chez free pour le moment !
 
Et toi, çà marche toujours pas ?

Une heure après, ca marchait toujours pas.
Le pire, c'est que le même programme avec des données différentes en entré marche très bien.
Actuellement, ca ne marche toujours pas. Netscape me dit que  qu'aucune donnée n'est retourné.
Va faloir que je change d'hébergeur du coup et ma base est trop grosse pour être récupéré grace à phpmyadmin..
Va faloir que je me cré un programme pour la duliquer morceaux par morceaux.

Rectificatif, au troisième essaie, il me ressort le même message.

Le pb est que ton script prend trop de tps à s'éxécuter
 
essaie de mettre ça au début du script (si free autorise cette f°) : set_time_limit(0);

Je vasi essayer.
merci pour l'astuce.

par default le maximum time execution est de 30 secondes, si t'as page met plus de 30 seconde a s'executer c kil y a un pb.
s'il s'agit d'un parse ou autres chose du style, free ne convient pas, ca m'etonnerait kil te laissent augmenter le delai d'execution de tes scripts

Bon, j'ai commencer mes essaies afin de trouver d'où proviendrais cette lenteur.
Pour le set_time_limit(0); , c'est inactif chez free.

utilise ca pour debuguer:
place ca tout en haut de ta page:
 function getmicrotime()
  {  
  list($usec, $sec) = explode(" ",microtime());  
  return ((float)$usec + (float)$sec);  
  }  
 $time_start = getmicrotime();
 
et ca a divers endroit:
 $time_end = getmicrotime();
 $time = $time_end - $time_start;
 
 echo "page générée en ".round($time,3)." secondes";

Merci speedyop, je vais essayer ta fonction.
ca me donera une idée de la durée de traitement dasn les cas qui marches.
 
Actuellement, mon code fait :

• 3 include,
• un des include lis un fichier de modèle de site,
• je fais en plus une ouverture de session de bdd,
• vers cette base là, je fait deux requêtes, une de mise à jour et une de lecture de 50 enregistrements,

je traite ces 50 enregistrement pour transformer les balises qu'il contiens en code html et en chemin vers des images.
 
 
 
Voilà ce que fait le code que j'utilise.
 
me reste plus qu'à mesurer la vitesse du code grace à ta fonction.

Bon, vopilà les résulstats des tests que je vizens de faire:
 
includes + chargement du modèle : 0.3 à 3 secondes
accés à la bdd : 3 à 7 seconde
traitement des donées : mois de 5 seconde (avant la ccoupure du traitement)
 
Durée totale constaté au bout de plusisuers tests : mois de 16 secondes.
 
Bref, free coupe bien avant les 30 secondes. Si le traitement durée 30 seconde, j'aurais pas de problèmes car je traite déjà plus de 30 chaines retournée par la bdd sur les 50 et ce n'est aps la partie qui prends le plus de temps.

Suite des tests: Ce soir, le script fonctionne bien dans la chambre de chat qui pose problème.
La page est généré en un peu plus de 20 secondes.
Par contre, une autre chambre de chat pose problème et l'arrêt pour temps d'éxécution ce passe mois de 2 seconde après le début du traitement.
Ils font vraiment chier avec ce progblème.
On peut vraiment pas savoir comment ils ont fait leur réglage vu que la duré maximùale auquel on a droit semble variable.

bah si function phpinfo();
regarde la je vient de te faire une page : http://speedyop.free.Fr/php.php3 apparement c fixer a 5sec!!!!!!

Au fait, tu pourrais afficher le temps a plusieurs endroits et faire des flush(), ce qui permettrait de voir le resultat, meme si ton script se fait jeter, tu as jusqu'au flush

Je fais plusieurs echo de durée.
Le max que j'ai eu dépâssé les 20 secondes alors que dans d'autres cas, je me fais jeté à un poil plus de 2 seconde.
Ils ont des problèmes de réglage on dirait.
 
En plus, 5 secondes, c'est beaucoup trop cours. Maintenant, je comprends pourquoi plein de site en php ont des problèmes en heure de pointe quand ils sont hébergé par free.

bah faut les comprendre quand meme que un sreveur doit heberger plein de site alors les ressources doivent etre partagé...

Mais je les comprends.
C'est jsute que 5 seconde, c'est un poil court pour beaucoup de cas.

Bon, on trouve une partie de mon code à l'adresse :
http://forum.hardware.fr/forum2.ph [...] owntopic=1
C'est un code de gestion de smilies et de formatage de texte.
bonne lecture pour ceux qui veulent y jeter un oeuil.

[citation][nom]
includes + chargement du modèle : 0.3 à 3 secondes
accés à la bdd : 3 à 7 seconde
traitement des donées : mois de 5 seconde (avant la ccoupure du traitement)
[/citation]
 
pas normal que l'acces mysql+recherche/select prenne autant de temps, j'ai fait un bench y a pas longtemps sur une base qui comptait 250000 entrées et une recherche avec une req exp mysql prennait - de 5sec pourtant c'est relativement lourd pour le serveur !
 
as tu bien indéxé les bonnes colonnes ?
tu utilises des tailles de champ optimal ?
et les bons types de données ?
 
pareil, vire les colonnes NULL et remplace les par des NOT NULL ->> NULL apporte rien et alourdit la base et ralentit les requetes ..etc tu as plein de petit truc simple a faire mais surtout si tu as des requetes croisés il faut bien avoir pensé ta base des le depart .
 
passe toutes tes requetes a la moulinette avec EXPLAIN, il apprend des choses surprenantes des fois

potiron a écrit a écrit :     pas normal que l'acces mysql+recherche/select prenne autant de temps, j'ai fait un bench y a pas longtemps sur une base qui comptait 250000 entrées et une recherche avec une req exp mysql prennait - de 5sec pourtant c'est relativement lourd pour le serveur !   as tu bien indéxé les bonnes colonnes ? tu utilises des tailles de champ optimal ? et les bons types de données ?   pareil, vire les colonnes NULL et remplace les par des NOT NULL ->> NULL apporte rien et alourdit la base et ralentit les requetes ..etc tu as plein de petit truc simple a faire mais surtout si tu as des requetes croisés il faut bien avoir pensé ta base des le depart .   passe toutes tes requetes a la moulinette avec EXPLAIN, il apprend des choses surprenantes des fois

Il faut pas oublier que c'est une base héberger chez free ce qui implique plusieurs centaines de requêtes en simultanées par serveur.
De plus, la requête qui va récupérer les 50 derniers messages d'une chambre de chat s'exécute sur une série de plus de 20 000 lignes. Je sais qu'il faudrait que je fasse un peu de vide mais ca fait presque deux mois que j'ai pas récupéré ma base et là, je peux plus a cause de la taille qu'est trop grande pour phpmyadmin.
Je suis entrein de me faire un script pour contourner le problème et ensuite, je ferais du ménage dans tout ça.
Pour les index, il faut que je vérifie que ca coresponde bien au champs de sélection mais ca devrai être bon.
Pour les champs NULL, je savais pas que ca pouvais jouer autant sur la rapidité. Je vérais ça.
Pour les taille de champs, j'ai deux champs surdimensionné (un bigint pour le numéro de réponse) et un champ texte pour le message en lui même. Sinon, les autres ont la taille minimale nécessaire.
Merci des infos.