Since you're collecting evidence, can you please try the exact same experiment, except serving up your big file via ExtImage and/or localFS? Thanks, Marc
From: ethan mindlace fremen <mindlace@digicool.com> Date: Tue, 17 Apr 2001 17:58:41 -0400 To: zope@zope.org Subject: Re: [Zope] large images to a database via zope.
--On Tuesday, April 17, 2001 11:51:11 +0100 Toby Dickenson <tdickenson@devmail.geminidataloggers.co.uk> wrote:
On Tue, 17 Apr 2001 05:00:35 -0400, ethan mindlace fremen <mindlace@digicool.com> wrote:
Well, a thread is locked for the entire time it is writing out to the end user. So get 4 simultaneous requests for a large file, and your site is now unresponsive (in a stock install.)
Im sure thats not true.
Here is my evidence:
Take zope (the .tgz) and stick it in your zope.
Get NetAnts (a windows program) and tell it you want to make >4 simultaneous "offset" requests for the same file, then download zope.tgz.
Try to get any other file from that zope with a regular browser, or run a light "ab" against it.
During the time that you are serving those offsets (which actually translates into serving the entire file), if # of requests > number of threads, your server will not answer to you.
Annoyingly, mod_proxy's cache mechanism decides that *it* can't handle offset requests, so it doesn't help any to cache.
This is actually a general problem for any non-filesystem image serving: Can you ask for BLOBS by offset?