Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a weird problem with Apache 2.2.15 on Windows 2000 Server SP4. Basically, I am trying to serve larger static files, images, videos etc. The download seems to be capped at around 550kB/s even over 100Mbit LAN.

I tried other protocols (FTP/FTPS/FTP+ES/SCP/SMB), and they are all in the multi-megabyte range. The strangest thing is that, when using Apache with HTTPS instead of HTTP, it serves very fast, around 2.7MByte/s! I also tried the AnalogX SimpleWWW server just to test the plain HTTP speed of it, and it gave me a healthy 3.3Mbyte/s.

I am at a total loss here. I searched the web, and tried to change the following Apache configuration directives in httpd.conf, one at a time, mostly to no avail at all:

SendBufferSize 1048576 #(tried multiples of that too, up to 100Mbytes)
EnableSendfile Off #(minor performance boost)
EnableMMAP Off
Win32DisableAcceptEx
HostnameLookups Off #(default)

I also tried to tune the following registry parameters, setting their values to 4194304 in decimal (they are REG_DWORD), and rebooting afterwards:

HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DefaultReceiveWindow
HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DefaultSendWindow

Additionally, I tried to install mod_bw, which sets the event timer precision to 1ms, and allows for bandwidth throttling. According to some people it boosts static file serving performance when set to unlimited bandwidth for everybody. Unfortunately, it did nothing for me.

So:

  • AnalogX HTTP: 3300kB/s
  • Gene6 FTPD, plain: 3500kB/s
  • Gene6 FTPD, Implicit and Explicit SSL, AES256 Cipher: 1800-2000kB/s
  • freeSSHD: 1100kB/s
  • SMB shared folder: about 3000kB/s
  • Apache HTTP, plain: 550kB/s
  • Apache HTTPS: 2700kB/s

Clients that were used in the bandwidth testing:

  • Internet Explorer 8 (HTTP, HTTPS)
  • Firefox 8 (HTTP, HTTPS)
  • Chrome 13 (HTTP, HTTPS)
  • Opera 11.60 (HTTP, HTTPS)
  • wget under CygWin (HTTP, HTTPS)
  • FileZilla (FTP, FTPS, FTP+ES, SFTP)
  • Windows Explorer (SMB)

Generally, transfer speeds are not too high, but that's because the server machine is an old quad Pentium Pro 200MHz machine with 2GB RAM. However, I would like Apache to serve at at least 2Mbyte/s instead of 550kB/s, and that already works with HTTPS easily, so I fail to see why plain HTTP is so crippled.

I am using a Kerio Winroute Firewall, but no Throttling and no special filters peeking into HTTP traffic, just the plain Firewall functionality for blocking/allowing connections.

The Apache error.log (Loglevel info) shows no warnings, no errors. Also nothing strange to be seen in access.log.

I have already stripped down my httpd.conf to the bare minimum just to make sure nothing is interfering, but that didn't help either.

If you have any idea, help would be greatly appreciated, since I am totally out of ideas!

Thanks!

Edit: I have now tried a newer Apache 2.2.21 to see if it makes any difference. However, the behaviour is exactly the same.

Edit 2: KM01 has requested a sniff on the HTTP headers, so here comes the LiveHTTPHeaders output (an extension to Firefox). The Output is generated on downloading a single file called "elephantsdream_source.264", which is an H.264/AVC elementary video stream under an Open Source license. I have taken the freedom to edit the URL, removing folders and changing the actual servers domain name to www.mydomain.com. Here it is:

LiveHTTPHeaders, Plain HTTP:

http://www.mydomain.com/elephantsdream_source.264

GET /elephantsdream_source.264 HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive

HTTP/1.1 200 OK
Date: Wed, 21 Dec 2011 20:55:16 GMT
Server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/0.9.8r PHP/5.2.17
Last-Modified: Thu, 28 Oct 2010 20:20:09 GMT
Etag: "c000000013fa5-29cf10e9-493b311889d3c"
Accept-Ranges: bytes
Content-Length: 701436137
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain

LiveHTTPHeaders, HTTPS:

https://www.mydomain.com/elephantsdream_source.264

GET /elephantsdream_source.264 HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive

HTTP/1.1 200 OK
Date: Wed, 21 Dec 2011 20:56:57 GMT
Server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/0.9.8r PHP/5.2.17
Last-Modified: Thu, 28 Oct 2010 20:20:09 GMT
Etag: "c000000013fa5-29cf10e9-493b311889d3c"
Accept-Ranges: bytes
Content-Length: 701436137
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain
share|improve this question
    
I'm sure you've already looked at this, but just to verify: are there any differences between the vhosts for HTTP and HTTPS, aside from the SSL directives? –  Shane Madden Dec 21 '11 at 16:36
    
I have checked the virtual hosts, and besides the SSL directives and the additional ServerName directive there is nothing special in the HTTPS vhost, so nothing that would hint at why it is so much faster when using HTTPS. –  Michael Lackner Dec 21 '11 at 17:40
    
Mostly curious, and to rule things out ... but (1) What is the difference in the headers for http vs https request? A tool like LiveHeaders on Firefox or Chrome's developer tools ought to help. (2) What is the system resource usage during an download, http vs https? (3) Are you using gzip compression anywhere in your configs? –  KM. Dec 21 '11 at 19:22
    
Ah, the good old LiveHTTPHeaders. I will edit the output into the original article (comment won't give me enough characters to post it). It will post the headers when downloading a 668MB .264 file. This file is a H.264/AVC elementary video stream, so that's considered incompressible content. I have taken the freedom to modify the URLs in the output. System resource use is quite low. When doing HTTPS there is almost full load on a single CPU, plain HTTP generates next to no load at all. Neither mod_deflate nor mod_gzip are being loaded by Apache, so I guess it's not the compression either.. –  Michael Lackner Dec 21 '11 at 21:05
    
I'd really like to see a comparative capture of SSL vs. HTTP here. This one has me really curious! –  mcauth Dec 21 '11 at 22:57

3 Answers 3

Quick and easy way to find if error is somewhere in Apache or in system environment: run XAMPP. It's properly configured and thoroughly tested. If problem exists in XAMPP, it's something about your firewall/antivirus/subtle system tuning.

share|improve this answer
    
I have downloaded the last VC6 build of XAMPP, which happens to be version 1.7.4. I will take a look in a few hours and then report back. –  Michael Lackner Dec 22 '11 at 13:52
2  
I am very sorry, but I can no longer do the XAMPP test. The entire machine just completely died. Unbelieveable... Who knows, maybe there was something very, VERY wrong already with it.. –  Michael Lackner Dec 22 '11 at 20:21

I rather suspect there is some intermediary getting in the way. Can you test using the client and server i the same subnet (i.e.. no router/firewall present)? Alternatively, try configuring Apache to listen on a different port (eg. 81) and see if there is still a difference.

In cases such as this, its usually something in the data-path that is inspecting HTTP traffic, such as a transparent security device or some (possibly transparent) proxy.

Alternatively, you could try tunnelling the http traffic over an SSH tunnel. If that is faster, then its a pretty strong indication that there is something on the network that is getting in the way.

Note that there could be client-side things (anti-malware components) on your client that get in the way too.

share|improve this answer

I've seen this before (sorry I'm late). Turns out in my case it was the ISP throttling traffic over port 80 to 512kbps, merely switching to a different port for the download fixed it. HTTP over port 81 for the win.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.