Bug #2589
closed40MB-100MB Quicktimes take minutes to load (CentOS, lighttpd 1.4.35, Chrome)
Description
CentOS 6.5
lighttpd 1.4.35 --with-openssl --with-fam
mod_h264_streaming 2.2.9
Chrome 36.0.1985.143
Quicktime plugin 7.7.3
Certain Quicktime movies of size > 40 MB that used to play instantly now consistently take minutes to begin playing (blue Quicktime "Q" appears, so plugin is loading but taking many minutes to work.)
Specs of a sample Quicktime that takes minutes to load:
File size: 46.15 MB
Format: Apple MPEG4 Decompressor, 1920 x 1080, Millions
FPS: 24
Data rate: 119 mbits/s
Duration 3.25 s
For comparison, specs of a sample Quicktime that loads instantaneously:
File size: 23.51 MB
Format: Apple MPEG4 Decompressor, 1920 x 1080, Millions
FPS: 24
Data rate: 47.34 mbits/s
Duration 4.16 s
The quicktime is embedded like so in a CGI page served with fastcgi:
<EMBED
SRC="{{ path }}"
WIDTH=1080 HEIGHT=720
TYPE="video/quicktime"
CONTROLLER="true"
scale="aspect"
PLUGINSPAGE="http://www.apple.com/quicktime/download/"
/>
- Lag can be observed on a sandbox server with no other traffic.
- Same lag occurs in Safari, as well as on client VMWare IE & Chrome
- Lag does not occur when serving same file via apache.
- Downloading problem Quicktimes (rather than playing them) is near-instantaneous.
- strace reveals that lighttpd spends 70-90% of the lag time waiting (epoll_wait).
- Installation of mod_h264_streaming v 2.2.7 on lighttpd has no effect.
- Altering lighttpd.conf IO preferences (see attached lighttpd.conf and sysctl.conf) has no effect.
- There is a suggestion online that lighttpd must be run as root for sysctl.conf changes to take effect. That doesn't make sense to me, as the clear preference for security is to run lighttpd as a normal user.
-There is a suggestion online that the video's index file needs to load completely before the video can play. If this is the culprit, I would love to know more.
If the issue is some combination of codec/hinted streaming/other distinguishing feature of the problem Quicktimes, then 1) bizarre that the lag is so great and yet eventually resolves and 2) I have no control over that.
Thank you for your attention. Any guidance will be appreciated.
Files
Updated by stbuehler over 9 years ago
- Downloading problem Quicktimes (rather than playing them) is near-instantaneous.
This makes it sound more like a client problem (although you point out this doesn't happen with apache).
- strace reveals that lighttpd spends 70-90% of the lag time waiting (epoll_wait).
This is exactly what you want. Blocking on epoll_wait means there was nothing for lighttpd to do.
Updated by AteYourLembas over 9 years ago
Thank you for these notes. I agree that the problem smacks of a client issue. Until the Apache test, I operated under the assumption the issue was a defective Quicktime plugin. (Even now I'm not convinced Quicktime isn't contributing to the problem.)
It's good to hear that the epoll_wait blocking is normal.
The test is on a local network, using a local file system, so I've been able to rule out firewall/network throttling issues, which is handy.
Updated by AteYourLembas over 9 years ago
Issue out to be a property of the problem QuickTimes--probably the codec.
Our solution is for lighttpd to serve them statically, e.g. add the following to lighttpd.conf:
alias.url = (
"/custommedia" => "/local/path/to/media"
)And then request the needed Quicktime via URL of the form:
http://our.local.host/custommedia/samplequicktime.movI hope this helps someone else.
Feel free to close this bug.
Updated by gstrauss about 8 years ago
I realize this is old, but on the off-chance you could provide more info, I am curious about this issue and would like to dig into it.
In all likelihood, the difference in behavior between Apache response and lighttpd response can be understood by looking at the HTTP response headers. What are the headers being sent in the HTTP request? What are the headers in the HTTP response that hangs? What are the headers in the HTTP response serving the static file, which does not hang?
The lighttpd.conf config params debug.log-request-header and debug.log-response-header might help collect this info.
Updated by AteYourLembas about 8 years ago
Thank you for taking up the cause, gstrauss, and thank you for the direction. It may take me a few days to get back into this, but I'll let you know what I learn.
Updated by AteYourLembas about 8 years ago
Pingback! In transition here and so very underwater. However looking forward to sitting down with this, and appreciating your efforts. Would be very good and interesting here to get it sorted. Will try this week. Feel free to ping any time...
Updated by patrickdk about 8 years ago
I don't see the url that was the problem.
If that url was being serviced via your fastcgi handler, then lighttpd will buffer that whole file (if your not using x-sendfile). Might be a contributing factor, and if it causes you to run out of memory (if your using a vps/vm/... services with low ram) and start swapping.
Updated by AteYourLembas about 8 years ago
Pingback. Let me see if I can get some time on this.
Updated by gstrauss about 8 years ago
- Status changed from New to Missing Feedback
@AteYourLembas: I'd still like to help you track this down, but it's been over 6 weeks and we're still waiting for more info, so I'm going to withdraw this ticket as "Missing Feedback". If you do find time to capture the request and response headers, as requested above, please reopen this issue or file a new one. Also, please include your lighttpd.conf.
Please see the note from patrickdk above about copying large files over fastcgi sockets when using fastcgi with X-Sendfile is much more efficient.
Updated by AteYourLembas about 7 years ago
This ticket can now officially be closed. The problem was caused by an incorrect configuration of Django on our end. Django was serving out the static media files rather than letting the webserver process do so. This slowed the downloads down considerably and disabled support for partial request downloads.
Big thanks to everyone for your patience and support. Making a little donation to show my appreciation.
Keep doing all you do!
Updated by gstrauss about 7 years ago
- Status changed from Missing Feedback to Invalid
Thanks for the update. Glad to hear that you tracked the problem down.
Marking "Invalid" since this is not a bug in lighttpd. (I do recommend latest lighttpd 1.4.45 as it handles large files from backends much better than 1.4.35. lighttpd 1.4.45 is slated to be part of Debian Stretch)
Also available in: Atom