php 'flush' funktioniert nicht

[chros]

Einen schönen guten Tag,

beim Implementieren einer Website auf der eigenen Synology NAS Webstation war es mir nicht möglich die php Funktion "flush()" zum laufen zu bekommen.

Zum Testen habe ich folgendes Skript verwendet:

<?php
header('Content-type: text/html; charset=utf-8');
for($i=0;$i<3;$i++)
{
    echo $i.'<br />';
    
    flush();
    if(ob_get_contents())
    {
        ob_flush();
    }
    
    sleep(1);
}
?>
-=[ END ]=-<br></font></center />

Auf einem lokalen XAMPP-Webserver funktioniert das Skript einwandfrei. Die Zählstand der Schleife wird im 1-Sekunden-Takt ausgegeben. Wird das gleiche Skript auf der Synology Webstation ausgeführt, so lädt dauert es ca. 3 Sekunden und die Seite erscheint im Ganzen.

Die Synology Webstation verwendet als Webserver Apache 2.2 mit PHP7.4.

Verschiedene anderen Themen aus Synology-Foren habe ich bereits durchsucht wie z.B.:
https://community.synology.com/enu/forum/17/post/78025

Einstellung in der php.ini wie "output_buffering" sind zwischen der Synology Webstation und dem lokalen XAMPP Webserver identisch.

Einstellungen in der php.ini, die es auf dem lokelen Webserver nicht gibt aber auf der Synology Webstation vorhanden sind beziehen sich auf den "opcache". Mir ist leider nicht bekannt wofuer "opcache" gut ist und ob es etwas mit den Problem zu tun haben könnte.

Hat jemand dieses Problem schon mal gehabt oder weiß alternativ woran es liegt?


Beste Grüsse,

Chros

 

[Fusion]

Mal mit PHP73 probiert?
In PHP74 sind eventuell noch nicht alle Falten ausgebügelt in der Syno-Implementierung.

 

[chros]

Besten Dank für den Vorschlag.
Habe eben einmal PHP 7.2 ausprobiert (war bereits installiert).
Leider kein Unterschied im Verhalten mit dem Test-Skript aus dem initialen Post.

 

[Fusion]

Mal schauen, ob es ein Performance-Problem ist und die Ausgabe nur z.B. alle 5 Sekunden machen?

 

[chros]

Hallo Fusion,
leider ebenfalls nicht. Habe bereits längere Zeiten als 5 Sekunden probiert.
Das Skript lädt dann lediglich entsprechend länger - grundlegendes Verhalten bleibt aber gleich.

Das Modell ist eine DS213+, also schon ein wenig älter. Bis auf meine Daten speichern & sichern und den Webserver betreiben macht das Gerät nicht viel. Kein Streaming, keine Cloud, keine Surveillance-Anwendungen, kein Minecraft-Server etc...

Beste Grüsse und vielen Dank,

Chros

 

[Ulfhednir]

Auch Apache-Module wie mod_gzip puffern zum Teil Ausgaben und verhindern so, dass Ausgaben nach flush() direkt an den Client weitergegeben werden.

https://www.php.net/manual/de/function.flush.php
Ich würde mal im Auschluss-Prinzip die Extensions deaktivieren und prüfen, ob sich dabei etwas verändert.

 

[chros]

Guten Morgen Ulfhednir,

besten Dank für diese Idee. In den Erweiterten PHP Einstellungen der Webstation habe ich soweit alle Module ausgeschaltet die für den Betrieb meiner Webseite nicht benötigt werden. Noch aktiv sind:

• bcmath
• calendar
• curl
• intl
• mysqli
• openssl

Hier ein Screenshot der Einstellungen. Die Option "Enable PHP Cache" habe ich mehrfach an- und ausgeschaltet - keine Veränderung bzgl. der flush()-Funktion.


Ob irgendwelche Apache-Module die flush()-Funktion behindern kann ich derzeit nicht sagen. Ich konnte keine Anleitung finden, mir die aktiven Module per SSH Terminal auf den NAS anzeigen zu lassen. Etwaige Anleitungen mittels "apache2ctl" sind für das NAS nicht anwendbar und in der Hilfe von Synology oder in Foren konnte ich nichts finden. Mein eigenes Wissen reicht dafür nicht aus.

Kennt jemand vllt. eine Anleitung die aktiven Apache-Module zu anzeigen zu lassen und ggf. zu aktivieren/deaktiveren?


Mit besten Grüßen,

Chros

 

[Ulfhednir]

Versuch es mal mit PHP-Info. Ich bezweifle aber, dass die Informationen dir weiterhelfen werden...

<?php
phpinfo();
?>

Du kannst auch mal mit output_buffering expermienterien:
https://stackoverflow.com/questions/4481235/php-flush-ob-flush-not-working/34996555

 

[chros]

Hallo,
in der Tat kann ich mit den meisten Informationen der phpinfo-Ausgabe wenig Anfangen. Was ich aber gesehen habe ist, dass die ServerAPI FastCGI verwendet. Kann es etwas damit zu tun haben?

 

[chros]

Hallo nochmal,
mit dem output_buffering habe ich bereits Versuche unternommen - ohne Ergebnis. Zudem ist diese Einstellung bei den lokalen XAMPP Webserver identisch - wo die flush()-Funktion einwandfrei funktioniert.

Die Option implicit_flush ist standard-mäßig aktiviert:


Auch den mögliche Buffer zu füllen mittels

echo str_pad('',4096)."\n";

habe ich probiert.

Die zlib-Erweiterung ist nicht aktiviert und gzip kann ich nirgend als Option finden, taucht aber als gültige Encoding-Methode in der phpinfo auf:


Kann man das irgendwie unterbinden/prüfen was der Webserver da macht?


Beste Grüße und vielen Dank,

Chros

 

[chros]

Ein kleines Update von meiner Seite aus:
Die Ausführung des folgendes Skripts dauert laut Messung um die 3,025 Sekunden, wie erwartet.

Hier das Skript:

$start_time = hrtime(true);
?>
<center><font face=courier size=20>-=[START]=-<br />
<?php
for($i=0;$i<3;$i++)
{
    echo $i.'<br />';
//    echo str_pad(' ', (4096 * 16 * 16 * 8) - 1) . "\n";
    
    flush();
    if(ob_get_contents())
    {
        ob_flush();
    }
    
    sleep(1);
}
?>
-=[ END ]=-<br></font></center />
<?php
echo "Execution time: " . round(((hrtime(true) - $start_time)/1e+6)/1000, 3) . " seconds<br>";

Die Seite lädt und erscheint dann im Ganzen. Keine Teile der Seite werden ausgegeben.


Wird die Funktion std_pad einkommentiert, so werden Teile des Skript ausgegeben - wie gewünscht an sich.
Allerdings verlängert sich die Ausführungszeit auf ~5,2 Sekunden (~+72%). Dies Verständlich meiner Meinung nach, da durch die str_pad Funktion der Buffer des Webservers mit 8MB Sinn-freien Leerzeichen "zugemüllt" wird.

Die Frage ist nun, wo der Buffer herkommt und wie man dieses ggf. anders konfigurieren kann?

Auf der Seite https://www.php.net/manual/de/function.flush.php gibt es folgenden Kommentar:

When using PHP with mode CGI/FastCGI there is a new buffer (initiated by mod_fcgid with a default size of 65536 bytes). That causes `flush()` and `ob_flush()` not working as expected with implicit_flush(true).
Setting "OutputBufferSize 0" in mod_fcgid config resolves the issue.
Hope it helps !

Hat jemand eine Idee oder Ahnung, wo ich die mod_fcgid config auf dem NAS finden kann??


Beste Grüsse,

Chros

 

[Ulfhednir]

Die Config vom Apache wäre unter:
/volumeX/@appstore/Apache2.4/usr/local/etc/apache2X/conf/

Dort wird zumindest auch das Modul initialisiert:

LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so

eine extra Config habe ich hier nicht gesehen. Mutmaßlich wäre die manuell unter /conf/extra/ zu erstellen und dann zu includen
So passiert es zumindest mit anderen configs:

Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-autoindex.conf
Include conf/extra/httpd-languages.conf
Include conf/extra/mod_xsendfile.conf
Include conf/extra/mod_rpaf.conf

 

[chros]

Hallo Ulfhednir,

danke für die Pfad-Informationen. Habe entsprechend der FastCgi die ich finden konnte
(z.B. https://docs.oracle.com/cd/B14099_19/web.1012/q20204/mod_fastcgi.html#FastCgiExternalServer)
jeweils das -flush Argument mit eingefügt:



Nach einem Neustart des gesamten NAS (uns somit auch der Webstation-Applikation und Apache) hat sich nichts geändert.

Installiert und verwendet wird PHP 7.4.. Mir ist nicht klar, warum bei dem unteren FastCgiExternalServer "php70" steht?
Auch ist mir nicht klar, wie man den Effekt der Argumente auf den Webserver testen kann?
Kann man irgendwo sehen, ob diese Einstellungen übernommen oder generell geladen werden?
FastCgi muss ja als Prozess des Betriebssystems ausgeführt werden ? Kann man irgendwie damit kommunizieren und einen Status abfragen?

Ich bin hier mit meinem Wissen mehr als am Ende. Google scheint auch nicht mehr zu wissen. Wirkt wieder so wie ein Thema was jedem klar ist und daher niemand dazu eine Anleitung über die "banalen" Fragen schreibt....

Ich bedanke mich sehr bei allen die hierzu beigetragen haben. Hoffentlich hilft das Support-Ticket direkt an Synology weiter.


Beste Grüsse,

Chros

 

[chros]

Hallo,

der Synology-Support konnte eine Lösung für dieses Problem finden:

If customer uses Apache 2.2 for virtual hosts:

In /var/packages/WebStation/target/misc/VirtualHost-apache22.mustache,

change

FastCgiExternalServer /vhost-{{.}} -socket /run/php-fpm/{{.}}.sock -idle-timeout 3600

to

FastCgiExternalServer /vhost-{{.}} -socket /run/php-fpm/{{.}}.sock -idle-timeout 3600 -flush

If customer uses Apache 2.2 as default http backend server:

In /var/packages/WebStation/target/misc/apache22.mustache,

change

FastCgiExternalServer /vhost-{{.}} -socket /run/php-fpm/{{.}}.sock -idle-timeout 3600

to

FastCgiExternalServer /vhost-{{.}} -socket /run/php-fpm/{{.}}.sock -idle-timeout 3600 -flush

In meinem Fall verwende ich Apache 2.2 direkt als Backend-Server. Die Eintragung des -flush-Arguments in der angegebenen Datei und ein Neustart der Apache 2.2 Applikation haben die flush()-Funktion von PHP aktiviert.

Zum Zeitpunkt dieses Beitrags ist die Version DSM 6.2.3-25426 Update 2 installiert.
Bei der Diskstation handelt es sich um eine DS213.


Mit besten Grüssen,

Chros