You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <ia...@cnet.com> on 2001/08/29 18:29:36 UTC
Streaming and a slow client
one of our developers over here came up with a interesting question.
say we have a GET request which gets served from a CGI or proxy. and it
is streamed/chunked out (which is the desired effect)
now lets say I have a VERY SLOW connection.
does this cause the server to hold onto the backend connection (ie..
keep the CGI/proxy alive) while the server is waiting for a response
back from the client.
this >could< be a DOS type attack.
..Ian
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Streaming and a slow client
Posted by Chuck Murcko <ch...@topsail.org>.
On Friday, August 31, 2001, at 04:42 PM, Ian Holsman wrote:
> On Fri, 2001-08-31 at 11:32, Graham Leggett wrote:
>> Ian Holsman wrote:
>>
>>> so are you suggesting we download the file first into our local cache,
>>> and then serve the file from there?
>>
>> Almost.
>>
>>> that won't work for streaming, as the client would have to wait for
>> the
>>> whole file to be present before it would get a single byte.
>>
>> Not at all.
>>
>> You download the file to the local cache, and *while* this is
>> happening,
>> you send the file downstream to the browser *at the same time*.
>>
>> Effectively you read from the backend and write to the file, and at the
>> same time you read from the file and write to the network.
>
> is this working at the moment?
>
> so all I need is a way to tell the cache not to actually 'cache' the
> result for the next request and I'll be happy
>
If it's really a stream, and there's no Content-Length (there can't be)
then we really need to do a bit more. You don't want the cached stream
to hog your cache, so the most robust solution is probably to circularly
buffer streams to some configurable length whether you're caching or not
and let the clients keep up as best they can. Heck, that's what the
clients themselves do.
None of this is HTTP/1.1 compliant AFAIK, so it'd be an extension,
perhaps by Content-Type.
I think Graham's cache solution is a most welcome improvement over 1.3
behavior.
Chuck Murcko
Topsail Group
http://www.topsail.org/
Re: Streaming and a slow client
Posted by Ian Holsman <ia...@cnet.com>.
On Fri, 2001-08-31 at 11:32, Graham Leggett wrote:
> Ian Holsman wrote:
>
> > so are you suggesting we download the file first into our local cache,
> > and then serve the file from there?
>
> Almost.
>
> > that won't work for streaming, as the client would have to wait for
> the
> > whole file to be present before it would get a single byte.
>
> Not at all.
>
> You download the file to the local cache, and *while* this is happening,
> you send the file downstream to the browser *at the same time*.
>
> Effectively you read from the backend and write to the file, and at the
> same time you read from the file and write to the network.
is this working at the moment?
so all I need is a way to tell the cache not to actually 'cache' the
result for the next request and I'll be happy
..I
>
> It is very important that this happens as it fixes a bug. The v1.3 cache
> has a problem where until an entity is downloaded in full, multiple
> requests will be made to the backend until at least one copy of the
> entity has been downloaded in it's entirety and cached. Up to this point
> there is a nasty load spike. The design of the new cache fixes this.
>
> Regards,
> Graham
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Streaming and a slow client
Posted by Graham Leggett <mi...@sharp.fm>.
Brian Degenhardt wrote:
> What about situations in which you don't want to cache the file, but just
> want to proxy it?
Use the Cache-Control directives properly, and the file will not be
cached.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Streaming and a slow client
Posted by Brian Degenhardt <bm...@mp3.com>.
What about situations in which you don't want to cache the file, but just
want to proxy it?
On Fri, Aug 31, 2001 at 08:32:33PM +0200, Graham Leggett wrote:
> Ian Holsman wrote:
>
> > so are you suggesting we download the file first into our local cache,
> > and then serve the file from there?
>
> Almost.
>
> > that won't work for streaming, as the client would have to wait for the
> > whole file to be present before it would get a single byte.
>
> Not at all.
>
> You download the file to the local cache, and *while* this is happening,
> you send the file downstream to the browser *at the same time*.
>
> Effectively you read from the backend and write to the file, and at the
> same time you read from the file and write to the network.
>
> It is very important that this happens as it fixes a bug. The v1.3 cache
> has a problem where until an entity is downloaded in full, multiple
> requests will be made to the backend until at least one copy of the
> entity has been downloaded in it's entirety and cached. Up to this point
> there is a nasty load spike. The design of the new cache fixes this.
>
> Regards,
> Graham
> --
> -----------------------------------------
> minfrin@sharp.fm "There's a moon
> over Bourbon Street
> tonight..."
Re: Streaming and a slow client
Posted by Graham Leggett <mi...@sharp.fm>.
Ian Holsman wrote:
> so are you suggesting we download the file first into our local cache,
> and then serve the file from there?
Almost.
> that won't work for streaming, as the client would have to wait for the
> whole file to be present before it would get a single byte.
Not at all.
You download the file to the local cache, and *while* this is happening,
you send the file downstream to the browser *at the same time*.
Effectively you read from the backend and write to the file, and at the
same time you read from the file and write to the network.
It is very important that this happens as it fixes a bug. The v1.3 cache
has a problem where until an entity is downloaded in full, multiple
requests will be made to the backend until at least one copy of the
entity has been downloaded in it's entirety and cached. Up to this point
there is a nasty load spike. The design of the new cache fixes this.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Streaming and a slow client
Posted by Ian Holsman <ia...@cnet.com>.
On Thu, 2001-08-30 at 15:16, Graham Leggett wrote:
> Brian Degenhardt wrote:
>
> > This is a huge pain in my neck. We stream/deliver mp3s through
> mod_proxy
> > and if you've got some guy on a 14.4 dialup downloading a 10meg mp3,
> the
> > backend server gets a connection tied up the whole time.
>
> This should be a feature of mod_cache.
>
> Incoming cached data should be written to the disk cache, but the data
> that is sent through downstream to the client should not be written at
> the same time as it is now - it should be read separately from the
> cached file. This way the fast backend and cache will rapidly fill the
> disk cache file and end the backend request, while the frontend request
> can be slow without being linked to the backend at all.
>
> How will this impact performance though when the network is fast?
>
so are you suggesting we download the file first into our local cache,
and then serve the file from there?
that won't work for streaming, as the client would have to wait for the
whole file to be present before it would get a single byte.
what we need IMHO is a non-blocking write on the client side (HTTP-OUT
filter I would guess) which wouldn't block until it gets a EOS
(not sure how hard this would be to implement)
> Regards,
> Graham
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Streaming and a slow client
Posted by Graham Leggett <mi...@sharp.fm>.
Brian Degenhardt wrote:
> This is a huge pain in my neck. We stream/deliver mp3s through mod_proxy
> and if you've got some guy on a 14.4 dialup downloading a 10meg mp3, the
> backend server gets a connection tied up the whole time.
This should be a feature of mod_cache.
Incoming cached data should be written to the disk cache, but the data
that is sent through downstream to the client should not be written at
the same time as it is now - it should be read separately from the
cached file. This way the fast backend and cache will rapidly fill the
disk cache file and end the backend request, while the frontend request
can be slow without being linked to the backend at all.
How will this impact performance though when the network is fast?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Streaming and a slow client
Posted by Gidon Wise <gi...@gidon.com>.
Why not use the cache to do this.
> > What's needed is some sort of disk based buffering mechanism.
>
> so we don't block on the client send?
>
> >
> > Would something like this be useful for the distribution? I've been playing
> > with mods like this on the side, if you guys want I might be able offer a
> > patch to accomplish this via a config directive.
>
> I'd be interested in this.
> it would stop us having to disable streaming
>
> ..Ian
>
Re: Streaming and a slow client
Posted by Ian Holsman <ia...@cnet.com>.
Brian Degenhardt wrote:
> This is a huge pain in my neck. We stream/deliver mp3s through mod_proxy
> and if you've got some guy on a 14.4 dialup downloading a 10meg mp3, the
> backend server gets a connection tied up the whole time.
>
not to mention the huge potential for DoS
(wouldn't even need proxy .. a simple CGI would do)
> It's tricky though. For cgi accellerators, you can rely on your tcp buffer
> size to pull in the whole document. However, you can't buffer 10 megs in
> ram because you'd run out of memory with just a handfull of streams.
> What's needed is some sort of disk based buffering mechanism.
so we don't block on the client send?
>
> Would something like this be useful for the distribution? I've been playing
> with mods like this on the side, if you guys want I might be able offer a
> patch to accomplish this via a config directive.
I'd be interested in this.
it would stop us having to disable streaming
..Ian
>
> On Wed, Aug 29, 2001 at 05:58:38PM -0400, Chuck Murcko wrote:
>
>>On Wednesday, August 29, 2001, at 12:29 PM, Ian Holsman wrote:
>>
>>
>>>one of our developers over here came up with a interesting question.
>>>
>>>
>>>say we have a GET request which gets served from a CGI or proxy. and it
>>>is streamed/chunked out (which is the desired effect)
>>>
>>>now lets say I have a VERY SLOW connection.
>>>
>>>does this cause the server to hold onto the backend connection (ie..
>>>keep the CGI/proxy alive) while the server is waiting for a response
>>>back from the client.
>>>
>>>
>>Yes, this is exactly what happens when you (mod_)proxy iTunes under Mac
>>OS X. If the client connection is slow enough, it fails and rebuffers
>>the stream periodically. But the backend connection stays open.
>>
>>Chuck Murcko
>>Topsail Group
>>http://www.topsail.org/
>>
Re: Streaming and a slow client
Posted by Brian Degenhardt <bm...@mp3.com>.
This is a huge pain in my neck. We stream/deliver mp3s through mod_proxy
and if you've got some guy on a 14.4 dialup downloading a 10meg mp3, the
backend server gets a connection tied up the whole time.
It's tricky though. For cgi accellerators, you can rely on your tcp buffer
size to pull in the whole document. However, you can't buffer 10 megs in
ram because you'd run out of memory with just a handfull of streams.
What's needed is some sort of disk based buffering mechanism.
Would something like this be useful for the distribution? I've been playing
with mods like this on the side, if you guys want I might be able offer a
patch to accomplish this via a config directive.
On Wed, Aug 29, 2001 at 05:58:38PM -0400, Chuck Murcko wrote:
>
> On Wednesday, August 29, 2001, at 12:29 PM, Ian Holsman wrote:
>
> >
> > one of our developers over here came up with a interesting question.
> >
> >
> > say we have a GET request which gets served from a CGI or proxy. and it
> > is streamed/chunked out (which is the desired effect)
> >
> > now lets say I have a VERY SLOW connection.
> >
> > does this cause the server to hold onto the backend connection (ie..
> > keep the CGI/proxy alive) while the server is waiting for a response
> > back from the client.
> >
>
> Yes, this is exactly what happens when you (mod_)proxy iTunes under Mac
> OS X. If the client connection is slow enough, it fails and rebuffers
> the stream periodically. But the backend connection stays open.
>
> Chuck Murcko
> Topsail Group
> http://www.topsail.org/
Re: Streaming and a slow client
Posted by Chuck Murcko <ch...@topsail.org>.
On Wednesday, August 29, 2001, at 12:29 PM, Ian Holsman wrote:
>
> one of our developers over here came up with a interesting question.
>
>
> say we have a GET request which gets served from a CGI or proxy. and it
> is streamed/chunked out (which is the desired effect)
>
> now lets say I have a VERY SLOW connection.
>
> does this cause the server to hold onto the backend connection (ie..
> keep the CGI/proxy alive) while the server is waiting for a response
> back from the client.
>
Yes, this is exactly what happens when you (mod_)proxy iTunes under Mac
OS X. If the client connection is slow enough, it fails and rebuffers
the stream periodically. But the backend connection stays open.
Chuck Murcko
Topsail Group
http://www.topsail.org/