On Mon, 18 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets cached
log (sql, db, whatever) that /blah/foo/bar.html is cached as
On Mon, 18 Sep 2006, Brian Akins wrote:
Graham Leggett wrote:
I have not seen inside the htcacheclean code, why is the code reading the
headers? In theory the cache should be purged based on last access time,
deleted as space is needed.
Everyone should be mounting cache directories noatime,
On 20/09/2006, at 06:20, Joe Orton wrote:
Hi Davi,
On Tue, Sep 19, 2006 at 11:34:03PM -0300, Davi Arnaut wrote:
Clean up code style in the cache code and shrink the mod_mem_cache
store_body function.
The casts to/from void * are unnecessary and could just be removed
rather than being
Davi Arnaut wrote:
Simplify the array and table serialization code, separating it from
the underlying I/O operations.
Probably faster to just put every thing in an iovec (think writev).
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Niklas Edmundsson wrote:
On Mon, 18 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
* Only one session caches the same file.
Easy to do if we use deterministic tmp files and not the way we
currently do it. Then all you have to do is when creating temp files
use O_EXCL.
Or,
Niklas Edmundsson wrote:
don't care about performance...
Actually, cache on xfs mounted with atime doesn't seem to be a
performance killer oddly enough... Our frontends had no problems
surviving 1k requests/s during the latest mozilla-update-barrage.
1k requests/second is not really that
Graham Leggett wrote:
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple
files and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
* No index/files
On 20/09/2006, at 10:16, Brian Akins wrote:
Davi Arnaut wrote:
Simplify the array and table serialization code, separating it from
the underlying I/O operations.
Probably faster to just put every thing in an iovec (think writev).
Probably no, apr_brigade_writev does (quite) the same.
--
Davi Arnaut wrote:
On 20/09/2006, at 10:16, Brian Akins wrote:
Davi Arnaut wrote:
Simplify the array and table serialization code, separating it from
the underlying I/O operations.
Probably faster to just put every thing in an iovec (think writev).
Probably no, apr_brigade_writev
On Wed, 20 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
don't care about performance...
Actually, cache on xfs mounted with atime doesn't seem to be a performance
killer oddly enough... Our frontends had no problems surviving 1k
requests/s during the latest mozilla-update-barrage.
On 20/09/2006, at 11:00, Brian Akins wrote:
Davi Arnaut wrote:
On 20/09/2006, at 10:16, Brian Akins wrote:
Davi Arnaut wrote:
Simplify the array and table serialization code, separating it
from
the underlying I/O operations.
Probably faster to just put every thing in an iovec
On 20/09/2006, at 11:58, Davi Arnaut wrote:
On 20/09/2006, at 11:00, Brian Akins wrote:
Davi Arnaut wrote:
On 20/09/2006, at 10:16, Brian Akins wrote:
Davi Arnaut wrote:
Simplify the array and table serialization code, separating
it from
the underlying I/O operations.
Probably
On 9/19/06, Davi Arnaut [EMAIL PROTECTED] wrote:
Remove duplicated defines.
Applied in r448226. Thanks,
-garrett
Issac Goldstand wrote:
I don't understand why bother getting so complex. Touch/truncate the
body file when storing the header, and then a missing body means things
have gone amok - retry the request. Conversely, a zero-length, or C-L
body length means another thread is working on the body.
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
I am not sure what the current cache code does to handle chunked entities
Brian Akins wrote:
Issac Goldstand wrote:
I don't understand why bother getting so complex. Touch/truncate the
body file when storing the header, and then a missing body means things
have gone amok - retry the request. Conversely, a zero-length, or C-L
body length means another thread is
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
I am not sure what the current cache code
On 09/20/2006 08:27 PM, Issac Goldstand wrote:
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
Ruediger Pluem wrote:
On 09/20/2006 08:27 PM, Issac Goldstand wrote:
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from
On 09/20/2006 09:59 PM, Issac Goldstand wrote:
Ruediger Pluem wrote:
First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
Yes, there is a reason why we cannot do this: This would create a possible
DoS, because we have to
suck in the whole response first before actually
Ruediger Pluem wrote:
On 09/20/2006 09:59 PM, Issac Goldstand wrote:
Ruediger Pluem wrote:
First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
Yes, there is a reason why we cannot do this: This would create a possible
DoS, because we have to
suck in the whole response first
This differs from a content coding in that the transfer-coding is a
property of the message, not of the original entity.
Based on that, it seems to be ok. However, we'd have to remove strong
ETags as a side-effect if it was done (since strong ETags change when
entity headers
tor 2006-09-21 klockan 00:19 +0300 skrev Issac Goldstand:
The only really relevant line I saw (in a quick 15 minute review) is RFC
2616-3.6 (regarding transfer-encodings):
Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained
24 matches
Mail list logo
