Greetings all,
I may finally have some time to work on some mod_cache issues that have
been nagging me. Mostly performance things. I really want to stop
maintaining my own version here, but to do that mod_cache needs to be
sped up a bit.
I'm setting up a dev environment now, so hopefully
Brian Akins wrote:
A short list I have (mostly mod_disk_cache):
-read_table and read_array seem slower than they should be
-thundering herd when a popular object expires
Thundering herd was one of the original design goals of the new cache
that was never fully followed through. With the
We tried to solve thundering herd problem wih cache-requester module
which I have not committed yet. It is currently available on source
forge.
I have not found enough time to work on it after summer of code was
over as I was busy with my thesis, internship. now I have just
relocated to calif
--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
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
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.).
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
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
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
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
27 matches
Mail list logo
