Large file downloading - slow response - solved.
Oh rat's ass. I spent about an hour trying to find the reason for Zope's slow performance, when serving large files until I found that it is the way Zope at the moment works. That it takes time to read the file into memory, create the temp-file and send it to the client. For my 8 MB file it took about a minute ( I logged it with the -M option ). Now my question is, that is there a way of improving this performance and is that one minute time normal for others too? How have users responded, for example while using Document Library product with large files? Our installation is on a Linux box, where we have Apache and with rewrite-rules forward querys to Zope. For now I had to create a static directory, where I will store large files and access them in Zope via LocalFS. When served to a client I write urls so that the files are server directly from Apache. If you have any other ideas how to make things work better I would be delighted to know. -huima
Heimo Laukkanen wrote:
For my 8 MB file it took about a minute ( I logged it with the -M option ). Now my question is, that is there a way of improving this performance and is that one minute time normal for others too? How have users responded, for example while using Document Library product with large files?
Why not use LocalFS or ExtFile and stop trying to make Zoep do something it's nto supposed to ;-) cheers, Chris
Chris Withers wrote:
Heimo Laukkanen wrote:
For my 8 MB file it took about a minute ( I logged it with the -M option ). Now my question is, that is there a way of improving this performance and is that one minute time normal for others too? How have users responded, for example while using Document Library product with large files?
Why not use LocalFS or ExtFile and stop trying to make Zoep do something it's nto supposed to ;-)
Well actually it doesn't matter if I use LocalFS or ExtFile if I access the file through Zope, when I use LocalFS I also need to access the file outside Zope - ie. straigth with Apache. No problem there, for me the problem was that it wasn't said anywhere that this is a performance question and I should solve it like this. It took time and effort to find the answer from mailing list archive. Btw I am using Zope 2.3.2 are there any improvements in 2.4? ,-) -huima
On Mon, Sep 24, 2001 at 08:01:05PM +0300, Heimo Laukkanen wrote:
For my 8 MB file it took about a minute ( I logged it with the -M option ). Now my question is, that is there a way of improving this performance and is that one minute time normal for others too? How have users responded, for example while using Document Library product with large files?
Odd. It took me about 3 seconds to download a 13MB tgz file from the ZODB (no LocalFS, no ExtFile) on the local network. The file is at http://www.cae.tntech.edu/help/unix/gnucash_tgz if you're interested in comparing. We do have Apache with mod_rewrite/mod_proxy sitting in front of Zope 2.3.2, too. So it might be a local configuration issue, I don't think we've done anything odd with Zope, and anything relevant we've done in Apache should be documented in my Vhost docs at www.zope.org/Members/mwr -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- renfro@tntech.edu
Heimo Laukkanen writes:
I spent about an hour trying to find the reason for Zope's slow performance, when serving large files until I found that it is the way Zope at the moment works. That it takes time to read the file into memory, create the temp-file and send it to the client. You may try HTTP streaming mode ==> "HTTPResponse.write".
Several threads in the mailing list archives .... Dieter
On Tue, 25 Sep 2001 23:35:35 +0200 (CEST), Dieter Maurer <dieter@handshake.de> wrote:
Heimo Laukkanen writes:
I spent about an hour trying to find the reason for Zope's slow performance, when serving large files until I found that it is the way Zope at the moment works. That it takes time to read the file into memory, create the temp-file and send it to the client. You may try HTTP streaming mode ==> "HTTPResponse.write".
Several threads in the mailing list archives ....
The standard File and Image objects already use RESPONSE.write! Toby Dickenson tdickenson@geminidataloggers.com
participants (5)
-
Chris Withers -
Dieter Maurer -
Heimo Laukkanen -
Mike Renfro -
Toby Dickenson