a release candidate for Apache-Test 1.13 is now available.
http://perl.apache.org/~geoff/Apache-Test-1.13-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
--Geoff
Changes since 1.12:
Geoffrey Young wrote:
a release candidate for Apache-Test 1.13 is now available.
http://perl.apache.org/~geoff/Apache-Test-1.13-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
All tests
--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
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 '\0' in
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
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
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
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
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 outperform
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 +
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
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.).
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
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 (like
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 into:
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
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
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
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.
What's the
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
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
: -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
--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 been
--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 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
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.
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
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.
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
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
--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
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 CHANGES
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
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
-- 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] 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 to get the votes to
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] wrote:
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
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
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
to
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 thought
41 matches
Mail list logo
