Fix for large file download problem?

You might want to consider looking into initiating your downloads with
the Apache module mod_xsendfile.

Right now, your downloads are piping through a php script as you may
already know. The php script's memory consumption increases exponentially
as the script is left open. Once the download is held open for a while,
the script hits our shared server's memory limit and is killed off. The
memory limit is in place to keep our shared servers happy and stable for
you and other customers, so it's not something I can circumvent for you.

Utilizing mod_xsendfile in your download script will initiate the
download via HTTP, then close the php script so memory isn't run up. It
also allows masking of the file location.

Here's some more information on how to implement mod_xsendfile in your
download script:

http://codeutopia.net/blog/2009/03/06/s ... e-and-php/

Just follow the instructions under the "Sending files" section. If this
is something you'd like to implement for your domain, please let me know
in a reply to this email, as there are a few things I have to do from
this end.

TraderDan wrote:How is it that, with the same host company, ZC could vend these large downloads without incident and yet OC has so many problems? Any further insight is greatly appreciated, thanks.

TraderDan wrote:Anyone? Bueller...?

TraderDan wrote:How is it that, with the same host company, ZC could vend these large downloads without incident and yet OC has so many problems? Any further insight is greatly appreciated, thanks.

    header("Content-Type: application/force-download");
    header('Content-Disposition: attachment; filename="' . ($mask ? $mask : basename($file)) . '"');
    header("Content-Length: " . filesize($file));
    header("Expires: 0");
    header("Last-Modified: " . gmdate("D,d M Y H:i:s") . " GMT");
    header("Cache-Control: no-cache, must-revalidate");
    header("Pragma: no-cache");

BlueHost Level III Tech Support wrote:In reviewing the module in question, there doesn't appear to be any significant advantage to this module, while it does in fact introduce a whole slew of headaches for server security and the sandboxing that we employ for customer accounts.

I would expect that the issues you are seeing currently are not due to instabilities in Apache's normal file serving methods, but are instead the result of our resource management daemons which will terminate running processes after a period of time. Currently the limit for a Webserver based process is 10 minutes. After a website process exceeds 10 minutes, it will be terminated, which is born out in our logs where it appears that the resource daemon has been regularly encountering long running Apache processes for your account which have had to be terminated after 600 Seconds (10 minutes.)

I'm afraid that an alternate Apache module for serving files will not work around this limit, it is hard-coded into the server kernel that certain processes should only be allowed to operate for predetermined periods of time.

Qphoria wrote:zencart does a "Webserver process" all the same.. anything from the http side will do it. Their code is functionally equivalent for the most part.

Copying files from your ftp doesn't count because that is a direct connection with no server processing. You could do that all day.

Qphoria wrote:How are you downloading it "all day" ? just going directly to the file with http://mysite.com/download/filename.zip ?