Concurrent requests to a single URL

[Yuri Khan <y....@2gis.ru>]

Hello,

I am evaluating Apache Traffic Server version 2.1.8-unstable as a 
reverse proxy for content distribution. Our main usage pattern is that 
once a month we release a bunch of new file versions (~20 to 150 MB 
each) and our users rush to download them. The files are released on the 
root server, and several reverse proxy servers handle users' requests, 
using the root server as origin.

A frequent situation, esp. early after the release, goes like this:

  * A user requests a file that is not yet cached.
  * The reverse proxy starts downloading the file from the origin, 
serving it to the user.
  * During this first request, another user requests the same file.

Ideally, we would like the second user's request to be handled using the 
same transfer that was initiated by the first user's request. 
Additionally, it would be handy if HEAD requests to the file that is 
being downloaded were handled based on the header that has already been 
received.

What I observe is that ATS opens another connection to the origin and 
requests the same file for GET requests, and HEAD requests are similarly 
forwarded to the origin.

I have tried these config settings:

CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
CONFIG proxy.config.cache.max_doc_size INT 0
CONFIG proxy.config.cache.enable_read_while_writer INT 1

as said in ticket TS-657, and the observed behavior does not change.

How does the read-while-writer feature work?

I have also read the discussion in TS-489 and it looks like connection 
collapsing is what we need. Should I try version 2.1.5-unstable with 
collapsing? I am not using clustering and should not be affected by that 
bug, right?

Re: Concurrent requests to a single URL

[Leif Hedstrom <zw...@apache.org>]

Did you enable read-while-writer? Search for rww in records.config. I've heard some mumbling about it not working as intended, but try it out.

-- leif

Sent from my iPad

On May 13, 2011, at 12:03 AM, Yuri Khan <y....@2gis.ru> wrote:

> Hello,
> 
> I am evaluating Apache Traffic Server version 2.1.8-unstable as a reverse proxy for content distribution. Our main usage pattern is that once a month we release a bunch of new file versions (~20 to 150 MB each) and our users rush to download them. The files are released on the root server, and several reverse proxy servers handle users' requests, using the root server as origin.
> 
> A frequent situation, esp. early after the release, goes like this:
> 
> * A user requests a file that is not yet cached.
> * The reverse proxy starts downloading the file from the origin, serving it to the user.
> * During this first request, another user requests the same file.
> 
> Ideally, we would like the second user's request to be handled using the same transfer that was initiated by the first user's request. Additionally, it would be handy if HEAD requests to the file that is being downloaded were handled based on the header that has already been received.
> 
> What I observe is that ATS opens another connection to the origin and requests the same file for GET requests, and HEAD requests are similarly forwarded to the origin.
> 
> I have tried these config settings:
> 
> CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
> CONFIG proxy.config.cache.max_doc_size INT 0
> CONFIG proxy.config.cache.enable_read_while_writer INT 1
> 
> as said in ticket TS-657, and the observed behavior does not change.
> 
> How does the read-while-writer feature work?
> 
> I have also read the discussion in TS-489 and it looks like connection collapsing is what we need. Should I try version 2.1.5-unstable with collapsing? I am not using clustering and should not be affected by that bug, right?

Re: Concurrent requests to a single URL

[Leif Hedstrom <zw...@apache.org>]

Meh, ignore my previous email.

-- leif

Sent from my iPad

On May 13, 2011, at 12:03 AM, Yuri Khan <y....@2gis.ru> wrote:

> Hello,
> 
> I am evaluating Apache Traffic Server version 2.1.8-unstable as a reverse proxy for content distribution. Our main usage pattern is that once a month we release a bunch of new file versions (~20 to 150 MB each) and our users rush to download them. The files are released on the root server, and several reverse proxy servers handle users' requests, using the root server as origin.
> 
> A frequent situation, esp. early after the release, goes like this:
> 
> * A user requests a file that is not yet cached.
> * The reverse proxy starts downloading the file from the origin, serving it to the user.
> * During this first request, another user requests the same file.
> 
> Ideally, we would like the second user's request to be handled using the same transfer that was initiated by the first user's request. Additionally, it would be handy if HEAD requests to the file that is being downloaded were handled based on the header that has already been received.
> 
> What I observe is that ATS opens another connection to the origin and requests the same file for GET requests, and HEAD requests are similarly forwarded to the origin.
> 
> I have tried these config settings:
> 
> CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
> CONFIG proxy.config.cache.max_doc_size INT 0
> CONFIG proxy.config.cache.enable_read_while_writer INT 1
> 
> as said in ticket TS-657, and the observed behavior does not change.
> 
> How does the read-while-writer feature work?
> 
> I have also read the discussion in TS-489 and it looks like connection collapsing is what we need. Should I try version 2.1.5-unstable with collapsing? I am not using clustering and should not be affected by that bug, right?