Hello,
Tu veux modifier combien de valeurs, en gros ? Je suppose que ta question porte sur http://planetalert.tuxfamily.org/newsboard/ qui ne semble pas bien rapide pour le peu d'informations qu'il affiche.
Du coup, on peut te donner quelques tuyaux pour ta question de base :
- c'est assez suspect tes ob_get_contents(), ob_flush() sans un ob_start() de ta part ; en fait, je ne suis même pas sûr que tu aies vraiment besoin des fonctions ob_* pour parvenir à tes fins.
- le str_repeat(' ', 256) ne fonctionne probablement pas parce que la sortie de PHP est utilisée pour constituer une réponse HTTP qui est elle-même bufferisée par un serveur Apache puis par un serveur nginx... du coup, ton 256 est un peu faiblard, tu peux y aller à grands coups de 16384 pour outrepasser la plupart des configs par défaut... mais ton code restera susceptible de se retrouver coincé dans un buffer quelconque sur d'autres environnements.
- tu peux aussi t'amuser avec l'en-tête "X-Accel-Buffering" reconnu par nginx ( http://nginx.org/en/docs/http/ngx_http_ … _buffering ) mais là, encore, ça n'est pas une mesure efficace dans tous les cas.
Au-delà se posent les questions de la façon dont les navigateurs reçoivent les infos (par exemple, 16384 espaces, une fois gzippés en cours de route, ça n'a plus forcément le même effet) et du rythme auxquels ils les interprètent.
Globalement, quand un traitement est vraiment long, il est d'usage de l'exécuter de manière asynchrone ; chez TuxFamily, ça peut prendre la forme d'un cron job. Une autre approche consiste à découper le traitement en petits morceaux (des lots de 5 joueurs par exemple) et à exécuter chaque morceau, typiquement un par un, via des requêtes HTTP émises en JavaScript (plus connu sous le nom d'AJAX) ; avec cette approche, c'est du JavaScript côté client qui se charge de demander au serveur de faire un certain travail, d'attendre la réponse pour ce travail et en fonction de cette réponse (HTTP 200 vs HTTP 50x) mettre à jour un petite barre de progression).
Voilà pour répondre à ta question technique au sens strict du terme. Maintenant, notre ressenti, c'est que tu utilises un CMS en guise de couche d'abstraction, probablement pour éviter de toucher à certaines technos que tu ne maîtrises pas ou mal (au hasard : SQL ?), et que cette couche d'abstraction est en train de te poignarder dans le dos en termes de performance (et on ne te cache pas que c'est SUPER-COURANT). Du coup, nous t'invitons non pas à te prendre la tête avec des histoires de buffering, de batchs, de traitements asynchrones, etc. mais plutôt à attaquer le problème à la source.
Ainsi, tu mentionnes une erreur 50x au bout de 30 secondes. En l'état actuel des limitations en place chez TuxFamily, un processus PHP peut s'exécuter pendant beaucoup plus longtemps que ça avant de rencontrer les divers timeouts d'Apache et nginx... mais par contre, il n'est pas autorisé à "manger" plus de 30 secondes de temps CPU (comprendre 100% CPU pendant 30 secondes). Nous pensons que c'est cette limite que tu atteins, et que tu l'atteins pour modifier un petit nombre d'enregistrements, c-à-d un traitement qui devrait être plié en moins d'une seconde et ne devrait pas nécessiter ce chantier anti-buffering que tu as attaqué.
Si tu nous donnes plus de détails sur ce que tu veux effectuer et comment tu l'as implémenté, nous pourrons te conseiller.