Jump to content

Slower downloads through Apache than with PHP readfile


pvp
Go to solution Solved by pvp,

Recommended Posts

I've set up a Download-Script with PHP on my server, which checks some details before letting the user download files via Apache (X-Sendfile). The Files are outside the Document-Root.

The code for downloading with Apache and the Module X-Sendfile is:

header("X-Sendfile: $fullpath");
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachment; filename=\"$link_file\"");

When using Apache and X-Sendfile i have a download-speed of 500 kB/s with my client. I also tested it with Apache and without X-Sendfile with the same file within the Document Root - same thing here!

So I tested downloading the same file, with the same client, the same infrastructure on both sides and the same internet-connection a few seconds later via PHP with readfile:

header("Pragma: no-cache");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Content-Type: application/octet-stream");
header("Content-Length: ".(string)(filesize($fullpath)));
header("Content-Disposition: attachment; filename=\"$link_file\"");
readfile($fullpath);

This time the download-speed was 9.500 kB/s!

 

I repeated this test using both options more than a multiple times and the result was the same every time trying. The only difference besides the download-speed was a waiting time of a few seconds (depending on the size of the file which was downloaded), when trying with the PHP readfile method. When repeating the PHP readfile method instantly, the waiting time didn't appear again. Most likely because it was stored in the memory after the first time.

I'm using a professional HP Raid-System on the server, which has an average local Speed of 800 MB/s, so the reason for this can't be the Diskspeed. Also i didn't find any compressing- or bandwith-settings in the httpd.conf of Apache.

Can anyone of you explain why there is such a great difference of the download-speed and how this can be changed?

Thank you in advance.

  • Server: Windows Server 2008 R2 Apache/2.2.21 (Win32) PHP/5.4.20
  • Client: Windows 7 Ultimate x64 Google Chrome 30.0.1599.101 LAN >100 Mbit/s

Link to comment
Share on other sites

My best guess would be that the method you are using to test the scripts makes it so that when using X-Sendfile the server has to read the file from disk, but when testing readfile it's reading from a memory cache loaded by the previous X-Sendfile test. Other than that, I would think you should be seeing roughly the same speed either way. I've not used X-Sendfile so I'm not very familiar with it. Are there any configuration settings that might need tweaking?

Link to comment
Share on other sites

Thank you for your reply.

 

I also tested it without X-Sendfile with "normal download" of Apache. Same speed as with X-Sendfile. The disk can't be the bottleneck (> 800 MB/s). If X-Sendfile would do caching, the download should be faster when trying a second time immediately afterwards. This is not the case.

Link to comment
Share on other sites

I tried it with activated gzip compression within Apache. Also i tried it with increased output buffering. No difference.

 

Besides: In my servers php.ini the output_buffering is set to 4.096, so this is not really much. In Apache i tried to increase the output-buffering up to 50.000 - no difference!

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.