Bonjour,
 
je butte sur un problème de temporisation de mes pages php chargées en ajax.
 
Je dois charger des listing de données qui peuvent aller jusqu'à 1500 enreg. ; le temps de chargement est de 12 à 14 secondes. Je cherche à réduire ce temps de chargement.
 
Pour cela j'essaie d'utiliser ob_start();
 
Mais premièrement le temps de chargement est toujours le même avec ou sans ob_start();
Deuxièmement, j'ai l'impression que ces instructions ne sont pas prises en compte par php, je m'explique :
 
Voici mon fichier ajax :

Mon fichier de class :

Come je l'ai dit, le temps d'affichage est exactement le même ; de plus si je ne mets pas de 'ob_end_flush()', aucun flux n'est renvoyé au navigateur. Mais le problème c'est que si je supprime effectivement le 'ob_end_flush()', les données sont quand même affiché par le navigateur !
 
S'agit-il d'une mauvaise utilisation de ma part des fct php ob_... ???
 
Le flux echo php ne devrait-il pas être renvoyé au navigateur QUE lors des appels de 'ob_end_flush()' ou de 'ob_flush()' ?
 
merci de vos réponses

Forcément que le temps est le même ... pourquoi il serait différent ?
 
En gros, dans un cas ça charge et affiche en même temps, dans l'autre cas ça charge d'abord, et affiche après. Aucune raison que ça accélère le temps de chargement.

il me semblait que l'intéret de ces fct était de pouvoir par exemple couper en plusieurs partie la réponse d'un script php, ce qui permettrait dans le cas d'un retour echo important (beaucoup d'enregistrement) de ne pas renvoyer au navigateur un gros flux en une fois, mais au contraire plusieurs flux de moindre importance successivement.
 
"Forcément que le temps est le même ... pourquoi il serait différent ? "
-> car c'est ce qu'on dit dans beaucoup de forum et également dans les livres que j'ai peu lire  
-> si ce n'est pas leur utilité à quoi servent ces fct ?
 
La deuxième question reste toujours en suspend :
 
"pourquoi les données que je mets dans mon tampon avec ob_start() sont elles envoyé au navigateur si je ne mets jamais ni ob_flush(), ni ob_end_flush();"

 
1> Personnellement je m'en sert dans mon framework. Les données sont traitées et récupérées mais non affichée, elles sont renvoyées au controller afin d'effectuer un traitement dessus, ou d'en enregistrer une partie dans un fichier de cache etc.
 
2> Elles sont envoyées au navigateur à la fin du chargement. Si dans tout le script tu n'as pas dis à Php quoi faire avec ce que tu lui as fais mettre en tampon, il le balance avant de "fermer".

alors je vous pose la question, existe t-il un moyen en php, pour retourner un flux navigateur en plusieurs petits "paquets" consécutifs au lieu d'un gros flots qui serait plus long à charger ? (car c'était le but initiale de mes tentatives)
 
merci

Si les datas sont récupérées en AJAX, c'est à l'appli d'aller récupérer les données en faisant passer une var pour dire "je veux le chunk 1", puis à reception une nouvelle requête avec "je veux le chunk 2" etc.
 
Même si tu fais une pause de temps en temps dans le script Php, je vois pas comment côté appli ça pourrait changer quelque chose. À partir du moment où il n'a pas réceptionné toute la page, il va attendre la suite.

oui vous avez raison, ce point ne m'avait pas échappé, mais le problème se posait plutot au niveau des ressources du navigateur client.
 
Lors d'un retour de flux important, la mémoire RAM que prend le navigateur au fur et à mesure qu'il réceptionne le script de retour va en s'accroissant. Je me disais qu'en renvoyant plusieurs petit "paquets" au lieu d'un gros ce problème d'occupation de la mémoire serait plus "étalé" dans le temps donc plus facile à manipuler pour le navigateur client. Mais apparemment cette manipulation ne peut se faire que par des requêtes ajax distincts et successives.
 
Je trouvais anormal qu'un tableau html que 4 ou 5 colonnes avec des données a afficher de facçon basique mette environ 15 secondes à s'afficher. Je cherche donc à diminuer ce temps d'affichage (car le processus serveur en lui même ne prends que qq ms, c'est le transfert des donénes du serveur vers le client qui prends beaucoup (trop) de temps)
 
Je vais donc chercher une autre alternative

"Je trouvais anormal qu'un tableau html que 4 ou 5 colonnes avec des données a afficher de facçon basique mette environ 15 secondes à s'afficher"  
-> pour 1500 enregistrements

ben pourquoi ne pas paginer?
sa gagne de la ressource du temps et si il veut que la fin il y va direct.
moi je préfère changer de page plutôt que scroller 1000lignes...

excellente remarque, mais mon responsable n'aime pas la pagination, donc....
 
merci quand même pour toutes vos réponses

 
Il préfère avoir 1500+ lignes en 1 page ?
 
Bonjour l'ergonomie