On Tue, 2004-08-03 at 22:29 -0400, Bill Stoddard wrote:
> mod_cache, mod_mem_cache and mod_disk_cache are experimental modules
> in 2.0, so I am going to bypass the votes
> and just start backporting fixes. Please review as they go in. If
> something breaks, we'll fix it. Mmmm K?
>
Whoa. I thoug
Bill Stoddard wrote:
Brian Akins wrote:
I think I missed the answer to this:
Has the "feature" that prevents mod_cache from caching urls ending in
/ (as related to mod_dir) been "fixed"? If so, will this make it into
2.0?
yes it has been fixed. I volunteer to help with the backport. Just need
Brian Akins wrote:
Justin Erenkrantz wrote:
That brings it in line with mod_disk_cache in maxing out my network.
Time to craft some better tests or find a faster network... -- justin
I can probably help with the latter :)
Can you send me details of your setup and I'll try to test later this wee
Justin Erenkrantz wrote:
--On Monday, August 2, 2004 11:44 AM -0400 Bill Stoddard
<[EMAIL PROTECTED]> wrote:
These are debug messages so not sure why they are a problem.
+0
The logging code is expensive to call for every request like that as
many times as it does. IMHO, there's no benefit to s
On Tue, 2004-08-03 at 15:22 -0400, Geoffrey Young wrote:
> hmm, I guess this fell off the collective radar.
>
> any comments? otherwise, I guess it's good enough and I'll just commit it
> to both 2.0 and 2.1.
Looks good to me.
-Paul Querna
> Geoffrey Young wrote:
> >
> > [EMAIL PROTECTED] wr
Brian Akins wrote:
I think I missed the answer to this:
Has the "feature" that prevents mod_cache from caching urls ending in /
(as related to mod_dir) been "fixed"? If so, will this make it into 2.0?
yes it has been fixed. I volunteer to help with the backport. Just need to get the votes to bac
-- Forwarded message --
From: Jeff Trawick <[EMAIL PROTECTED]>
Date: Tue, 3 Aug 2004 14:45:16 -0400
Subject: Re: [PROOF-OF-CONCEPT?] logging memory used by an allocator
To: Sander Striker <[EMAIL PROTECTED]>
On Sun, 1 Aug 2004 19:46:14 +0200, Sander Striker <[EMAIL PROTECTED]> wrot
I think I missed the answer to this:
Has the "feature" that prevents mod_cache from caching urls ending in /
(as related to mod_dir) been "fixed"? If so, will this make it into 2.0?
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
Mathihalli, Madhusudan wrote:
: -Original Message-
: From: Bill Stoddard [mailto:[EMAIL PROTECTED]
[SNIP]
: >
: > Here's some comparative numbers to chew on.
: >
: > One client and one server on 100Mbps network (cheapy
: 100Base-T switch);
: > 50 simulated users hitting 7 URLs 100 times
hmm, I guess this fell off the collective radar.
any comments? otherwise, I guess it's good enough and I'll just commit it
to both 2.0 and 2.1.
--Geoff
Geoffrey Young wrote:
>
> [EMAIL PROTECTED] wrote:
>
>>pquerna 2004/07/10 00:47:23
>>
>> Modified:.Tag: APACHE_2_0_BRANCH CH
--On Tuesday, August 3, 2004 2:35 PM -0400 David Nicklay
<[EMAIL PROTECTED]> wrote:
Send us your squid.conf and your configure options from when you built it
(as well as what squid version), and I can tell you how to optimize it.
I've had a lot of practice..
I've posted the squid.conf from RH
Hi,
Send us your squid.conf and your configure options from when you built
it (as well as what squid version), and I can tell you how to optimize
it. I've had a lot of practice..
Brian Akins wrote:
Justin Erenkrantz wrote:
--On Tuesday, August 3, 2004 8:11 AM -0400 Brian Akins
<[EMAIL PROT
Mathihalli, Madhusudan wrote:
.. Well, doesn't it depend upon the size of the data set. With 'ab', I
guess that's possible that mod_mem_cache can beat mod_disk_cache - but
with a dataset like SPECweb99, I'd really doubt if it can really do it.
BTW, I wonder how mem_cache can significantly out-perfo
Justin Erenkrantz wrote:
--On Tuesday, August 3, 2004 8:11 AM -0400 Brian Akins
<[EMAIL PROTECTED]> wrote:
Under load, squid will always use 100% of the CPU. This is because
it uses
poll/select.
Ouch. That sucks.
(But, httpd uses poll - so why does that force 100% CPU usage?)
httpd blocks. S
Justin Erenkrantz wrote:
That brings it in line with mod_disk_cache in maxing out my network.
Time to craft some better tests or find a faster network... -- justin
I can probably help with the latter :)
Can you send me details of your setup and I'll try to test later this week.
--
Brian Akins
S
Graham Leggett wrote:
mem cache and disk cache were created because not every platform
performs best using the same techniques.
This competition between mem cache and disk cache will hopefully make
them both faster, and in turn faster than other caches out there.
True. Competetion is good.
-
--On Tuesday, August 3, 2004 6:50 PM +0200 Graham Leggett <[EMAIL PROTECTED]>
wrote:
mod_mem_cache: Requests: 35000 Time: 54.90 Req/Sec: 637.81
no cache: Requests: 35000 Time: 54.86 Req/Sec: 638.81
The above result would suggest that mod_mem_cache isn't being used in this
case. It could be
--On Tuesday, August 3, 2004 9:12 AM -0400 Brian Akins <[EMAIL PROTECTED]>
wrote:
Propably not, because you would propably have to lock around it. It just
seems it's better to let the filesystem worry about alot of this stuff
(locking, reference counting, etc.).
+1. =) -- justin
--On Tuesday, August 3, 2004 8:11 AM -0400 Brian Akins <[EMAIL PROTECTED]>
wrote:
Under load, squid will always use 100% of the CPU. This is because it uses
poll/select.
Ouch. That sucks.
(But, httpd uses poll - so why does that force 100% CPU usage?)
RHEL 3 sucks. Fedora Core 2 would have bee
: -Original Message-
: From: Bill Stoddard [mailto:[EMAIL PROTECTED]
[SNIP]
: >
: > Here's some comparative numbers to chew on.
: >
: > One client and one server on 100Mbps network (cheapy
: 100Base-T switch);
: > 50 simulated users hitting 7 URLs 100 times with flood
: (35,000 reque
Brian Akins wrote:
mod_mem_cache is broken then. It used to kick the pants off of 'no
cache' and mod_disk_cache.
If mod_disk_cache was patched to use sendfile, it will perform better.
mem cache and disk cache were created because not every platform
performs best using the same techniques.
This
Bill Stoddard wrote:
mod_mem_cache: Requests: 35000 Time: 54.90 Req/Sec: 637.81
no cache: Requests: 35000 Time: 54.86 Req/Sec: 638.81
The above result would suggest that mod_mem_cache isn't being used in
this case. It could be that mem cache has decided not to cache the
requested file for
On Tue, 2004-08-03 at 08:18 -0400, Brian Akins wrote:
> Greg Ames wrote:
> > Bill Stoddard created an event driven socket I/O patch a couple of
> > years ago that could serve pages. I picked it up and decided to see
> > if I could simplify it to minimize the changes to request processing.
>
> Wh
Bill Stoddard wrote:
mod_mem_cache is broken then. It used to kick the pants off of 'no
cache' and mod_disk_cache.
If mod_disk_cache was patched to use sendfile, it will perform better.
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
Bill Stoddard wrote:
Justin Erenkrantz wrote:
--On Monday, August 2, 2004 2:49 PM -0400 Bill Stoddard
<[EMAIL PROTECTED]> wrote:
To get mod_cache/mod_mem_cache (I know little or nothing about
mod_disk_cache) really performing competatively against best-of-breed
caches
will require bypassing outp
Justin Erenkrantz wrote:
--On Monday, August 2, 2004 2:49 PM -0400 Bill Stoddard
<[EMAIL PROTECTED]> wrote:
To get mod_cache/mod_mem_cache (I know little or nothing about
mod_disk_cache) really performing competatively against best-of-breed
caches
will require bypassing output filters (and prebu
On Tue, 3 Aug 2004 10:19:23 -0400, Dan Wilga <[EMAIL PROTECTED]> wrote:
> The information contained in the access log can be quite useful in
> tracking down problems. However, because the log entry is created
> only after all output has been sent to the client, there is a problem
> I sometimes run
Dan Wilga wrote:
> The information contained in the access log can be quite useful in
> tracking down problems. However, because the log entry is created only
> after all output has been sent to the client, there is a problem I
> sometimes run into:
>
> If the child process creating the output (
The information contained in the access log can be quite useful in
tracking down problems. However, because the log entry is created
only after all output has been sent to the client, there is a problem
I sometimes run into:
If the child process creating the output (like a CGI script) dies
une
Graham Leggett wrote:
This is true - mem cache would probably improve drastically with a
shared memory cache.
Propably not, because you would propably have to lock around it. It
just seems it's better to let the filesystem worry about alot of this
stuff (locking, reference counting, etc.).
-
Brian Akins wrote:
The big hits for mem cache are:
The cache is not shared between processes, so you use alot more memory
and have a lot less "hits."
This is true - mem cache would probably improve drastically with a
shared memory cache.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptog
Eli Marmor wrote:
Graham Leggett wrote:
Brian Akins wrote:
On an OS that supports sendfile, a disk based cache will almost always
bury a memory based one.
Quite probably. But on a system without a disk, chances are it won't. :(
It will.
Unless mod_disk_cache + ram-disk + sendfil
Graham Leggett wrote:
>
> Brian Akins wrote:
>
> > On an OS that supports sendfile, a disk based cache will almost always
> > bury a memory based one.
>
> Quite probably. But on a system without a disk, chances are it won't. :(
It will.
Unless mod_disk_cache + ram-disk + sendfile doesn't outper
Brian Akins wrote:
On an OS that supports sendfile, a disk based cache will almost always
bury a memory based one.
Quite probably. But on a system without a disk, chances are it won't. :(
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Greg Ames wrote:
Bill Stoddard created an event driven socket I/O patch a couple of
years ago that could serve pages. I picked it up and decided to see
if I could simplify it to minimize the changes to request processing.
What's the status of this? I'd be willing to help if needed. We are
in
Bill Stoddard wrote:
Please, no more specialized knobs which 99.9% of the world cares
nothing about.
How do you define that percentage? By domains? In that case 99.999%
probably care nothing about what we are doing. If you look at total
traffic, however, would not options that help the to
Justin Erenkrantz wrote:
squid was really inefficient both CPU and network-wise.
Under load, squid will always use 100% of the CPU. This is because it
uses poll/select.
The squid numbers *completely* baffle me. I have to believe I've got
something stupid configured in squid (or I did someth
On Tue, 3 Aug 2004 11:45:51 +0900 (JST), Tsuyoshi SASAMOTO
<[EMAIL PROTECTED]> wrote:
> >attached patch looks a bit simpler; does it look okay to you?
>
> Yes, it looks good and smart.
>
> # I wonder about intention of the original code `if (!body)`;
if we received a message, it will have the '\
--On Monday, August 2, 2004 2:49 PM -0400 Bill Stoddard <[EMAIL PROTECTED]>
wrote:
To get mod_cache/mod_mem_cache (I know little or nothing about
mod_disk_cache) really performing competatively against best-of-breed caches
will require bypassing output filters (and prebuilding headers) and possib
39 matches
Mail list logo
