Graham Leggett wrote:
On 06 Sep 2010, at 11:00 PM, Paul Querna wrote:
Isn't this problem an artifact of how all bucket brigades work, and is
present in all output filter chains?
An output filter might be called multiple times, but a single bucket
can still contain a 4gb chunk easily.
It
On 13 Sep 2010, at 1:14 PM, Paul Fee wrote:
Retrieving bodies from the cache has a similar scalability issue. The
CACHE_OUT filter makes a single call to the provider's
recall_body(). The
entire body must be placed in a single brigade which is sent along the
filter chain with a single
On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote:
It is not a problem for mod_disk_cache as you say, but
I guess he meant for 3rd party providers that could only deliver
the cached responses via heap buckets.
The cache provider itself puts the bucket in the brigade, and has the
-Original Message-
From: Graham Leggett
Sent: Montag, 13. September 2010 16:35
To: dev@httpd.apache.org
Subject: Re: mod_cache: store_body() bites off more than it can chew
On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote:
It is not a problem for mod_disk_cache
Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Graham Leggett
Sent: Montag, 13. September 2010 16:35
To: dev@httpd.apache.org
Subject: Re: mod_cache: store_body() bites off more than it can chew
On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote
On 06 Sep 2010, at 11:00 PM, Paul Querna wrote:
Isn't this problem an artifact of how all bucket brigades work, and is
present in all output filter chains?
An output filter might be called multiple times, but a single bucket
can still contain a 4gb chunk easily.
It seems to me it would be
On Fri, 3 Sep 2010, Graham Leggett wrote:
snip
Regarding the issue of the disk cache cramming the entire file into
memory/address space, an alternate solution could be that the cache returns
buckets pointing to the cached file, ie that the cache consumed those pesky
mmapped buckets. This
On 06 Sep 2010, at 11:52 AM, Niklas Edmundsson wrote:
Regarding the issue of the disk cache cramming the entire file
into memory/address space, an alternate solution could be that the
cache returns buckets pointing to the cached file, ie that the
cache consumed those pesky mmapped buckets.
On Mon, 6 Sep 2010, Graham Leggett wrote:
snip
For those who have forgotten, that's what we do in our
large-file-caching-patchset for mod_disk_cache (hidden as an attachment to
https://issues.apache.org/bugzilla/show_bug.cgi?id=39380 but I should
really get around to upload an up2date version
On 2010-09-06 at 05:52, Niklas Edmundsson ni...@acc.umu.se wrote:
On Fri, 3 Sep 2010, Graham Leggett wrote:
Been keen to do this for a while, this would definitely solve the
RAM problem, but wouldn't solve the time problem. Copying 4GB of
data from a slow disk can easily take minutes, and
Graham Leggett wrote:
Given that the make-cache-writes-atomic problem requires a change to
the data format, it may be useful to look at this now, before v2.4 is
baked, which will happen soon.
How much of a performance boost is the use-null-terminated-strings?
Regards,
Graham
--
If
On 06 Sep 2010, at 3:10 PM, Paul Fee wrote:
If mod_disk_cache's on disk format is changing, now may be an
opportunity to
investigate some options to improve performance of httpd as a
caching proxy.
Currently headers and data are in separate files. If they were in a
single
file, the
On Mon, 6 Sep 2010, Paul Fee wrote:
If mod_disk_cache's on disk format is changing, now may be an opportunity to
investigate some options to improve performance of httpd as a caching proxy.
Currently headers and data are in separate files. If they were in a single
file, the operating system
On Monday 06 September 2010, Paul Fee wrote:
Currently headers and data are in separate files. If they were in
a single file, the operating system is given more indication that
these two items are tightly coupled. For example, when the
headers are read in, the O/S can readahead and buffer
On Thu, Sep 2, 2010 at 10:16 AM, Graham Leggett minf...@sharp.fm wrote:
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
On Thu, 2 Sep 2010, Graham Leggett wrote:
snip
Should however the cache implementation want to take a breath, it returns to
mod_cache with unconsumed bucket(s) still remaining in the in brigade.
mod_cache in turn sends the already-processed buckets in the out brigade
down the filter stack to
On 03 Sep 2010, at 4:25 PM, Niklas Edmundsson wrote:
This could even go a bit further with providing the cache
implementation with a hint of when it would be polite of it to
return. I think it would probably be easier if the cache
implementation knows what's expected of it. Or?
That I've
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
apr_bucket_brigade *b);
Right now, mod_cache expects a cache
On 09/02/2010 07:16 PM, Graham Leggett wrote:
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
apr_bucket_brigade
19 matches
Mail list logo
