Nextcloud version: 29.0.4
Operating system and version: Gentoo
Apache or nginx version : Lighttpd 1.4.76
PHP version: 8.2
When downloading big files through the web interface, there is a long delay, when the webbrowser seems to do nothing. For 4GB file it is around 90-120 seconds.
On the server I see php-fpm: pool www and lighttpd processes in D state. It looks like the php is reading all the file before deciding, what to do with it? (This is on a rotational disk, on SSD the delay might be lower.)
First, I thought, it is because it is a movie file (mkv), so it is trying to stream it or something. But happens to a large random file as well.
Maybe it is related to the way the file is put on the server? I copy it directly to the right folder on the server and then run occ files:scan --all in order to put it in the DB.
Is this the first time you’ve seen this error?: Y, some time ago I didn’t notice the delay. But I also didn’t use the occ files:scan --all before.
When downloading big files through the web interface, there is a long delay, when the webbrowser seems to do nothing. For 4GB file it is around 90-120 seconds.
By default lighttpd buffers entire response body before sending to the client. server.stream-response-body = 0
Change this config option to 1 or even 2 (ref link)
On local network, using option 2, I got speeds close to the maximum for my hardware. Of course, CPU load was significant, so for multiple Nextcloud users I would recommend option 1.
The difference between 1 and 2 is for lighttpd server.stream-response-body is how much intermediate buffering is done by lighttpd. Letting lighttpd buffer the response with server.stream-response-body = 1 allows the backend to finish serving the response more quickly and to free up those backend resources. lighttpd is much, much lighter than PHP. However, if you are sending large files and lighttpd is filling up /var/tmp buffering those responses, then server.stream-response-body = 2 is better to avoid lighttpd using so much space for temporary files.