Hi joe!
I do not know if you saw my questions this morning, but I have started back
using squid 2.5 pre4.
I have a quest.
How do you determine the hit ratio from these values?
Cache information for squid:
Request Hit Ratios: 5min: 13.4%, 60min: 15.1%
Byte Hit Ratios: 5min: 11.2%, 60min: 13.1%
Request Memory Hit Ratios: 5min: 17.9%, 60min: 24.6%
Request Disk Hit Ratios: 5min: 16.8%, 60min: 18.1%
Thank you very much.
Best regards,
Edward Millington. BSc, Network+
Systems Administrator
Cariaccess Communications Ltd.
Palm Plaza
Wildey
St. Michael
Barbados
1-246-430-7435
Fax : 1-246-431-0170
[EMAIL PROTECTED]
www.cariaccess.com
----- Original Message -----
From: "Joe Cooper" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 11, 2002 11:58 AM
Subject: Re: [OOPS] increasing the number of threads on linux
> Igor Khasilev wrote:
> > On Fri, 8 Mar 2002, Joe Cooper wrote:
> >
> >
> >>You're probably right about this. In many cases the benefits of threads
> >>outweigh the performance troubles--and Oops does a fine job keeping up
> >>with Squid up to a point and uses less resources to do it, generally.
> >>And achieving the absolute pinnacle of performance doesn't usually need
> >>to be the most important factor when designing any software. But then,
> >>threads also introduce a lot of their own problems that make debugging
> >>and maintaining the code more difficult. The fact that many Unix and
> >>Linux developers don't /like/ threads and so don't spend much effort
> >>
> >
> > It's pity. Multithreading is only real way to use several processors on
the
> > host.
>
>
> Not the /only/ way, but certainly a good one. TUX (the in-kernel
> webserver from Red Hat) utilizes one thread per processor. Works
> beautifully, without the overhead of thread-per-connection. But state
> machines can be more difficult to code in some cases.
>
> >>I did some benchmarking of Oops 2.2.18 and some 2.2.x version after
> >>2.2.18 (it was one of the experimental tarballs). I found it to perform
> >>extremely well at low request rates and client loads, but found
> >>performance topped out at 70 reqs/sec from hardware that could sustain
> >>about 110 from Squid. Because CPU wasn't a bottleneck, and I had plenty
> >>of memory, I had to assume the biggest problem was disk I/O contention
> >>with the BerkelyDB. So GigaBASE addresses this problem, somewhat?
> >>
> >
> > If CPU is not a bottleneck then most probably disk I/O with storages
(and
> > next with DB) is the problem. Since 1.5.18 there were significant
> > improvements in storage I/O area. In test environment (under polygraph)
> > due to aligned read/write to raw partition, speed of document swapout
> > increased near 5 times.
>
>
> Interesting. I will give the new version a go, in this case.
>
> > There was also some changes in swapout/dropout algorythms which allow
keep
> > memory usage under more constant control.
> >
> > Again, to avois OS-specific performance problem you should try it under
> > solaris.
>
> Solaris would be merely an academic exercise for me, which is something
> I don't have the luxury of pursuing these days. My options are Linux or
> FreeBSD (and FreeBSD has serious drawbacks for most of my needs). This
> is because we are a hardware vendor--shipping Sun boxes is not an option
> (and x86 Solaris will soon be end-of-lifed).
>
> However, I do have the luxury of using my own Linux kernel variant, and
> the knowledge needed to make just about any stable or beta patch in
> existence work well enough for my needs. So I can experiment with
> various threading implementations, and anything else needed to make
> things go.
>
> >>I'm not convinced that a DB style backend can provide a satisfactory
> >>performance level with multiple disks...but perhaps I'm wrong. It is
> >>
> >
> > I never seen that gigabase become bottleneck, storage io become first.
>
> Cool. I'll look into it. If it has crasher bugs as you mentioned in a
> previous message, I'll have to keep it on the back burner as an
> interesting but not-usable project. As you may know, my caching servers
> go out to clients at ISPs and other high-load, always-on, environments.
> Crashing software just won't do--I'd never get any sleep! ;-)
>
>
> >>the Right Way). It's quite likely that as it develops into something as
> >>solid as Squid, and has the primary features that my clients need I will
> >>
> >
> > Which features?
>
> For a total switch for all of my users (which isn't likely at all), I
> would need all of the following:
>
> Performance and stability to match Squid. I'll test to see if the new
> version matches up more closely.
>
> auth helpers (LDAP is necessary).
>
> Accelerator features as found in Henrik's rproxy patches. This allows
> multiple backend origin servers to be configured, much like cache_peers,
> which allows for high availability and load balancing and other fun stuff.
>
> Site compatibility to match Squid. I don't have enough data about Oops
> to know if it has any serious compatibility issues, but I know Squid is
> one of the most compatible proxies available.
>
> And probably a couple of other things I can't think of right now. I
> would also have to write all new maintenence tools--we have an entire
> suite of GUI components to make managing a Squid server easy and fun.
> Those would have to be rewritten mostly from scratch, because Oops is a
> very different animal.
>
> To convert our ISP clients (not accelerator and enterprise clients) we
> would only need solid transparent operation, WCCP (you've already got
> it--better than Squid probably), and performance to match or beat Squid
> on equal hardware (some of which is extremely large hardware--so Oops
> will have to scale pretty effectively to larger hardware are more disks).
>
>
> >>begin to support it alongside Squid.
> >>
> >>And for what it's worth, I think the idea of starting from scratch
> >>rather than patching Squid was probably a good one. Even the Squid
> >>developers seem to be leaning towards a near total rewrite for version 3
> >>of Squid. ;-)
> >>
> >
> > I can understend them :). I also started to rewrite oops half year ago,
when
> > I clear see what was wrong from the start.
>
> You say you 'started' to rewrite Oops. So does that mean you're
> maintaining two source trees? One rewrite and one old codebase...or
> have you converted the whole release version to a rewritten codebase? I
> have followed Oops development for about two years, but not very
> closely--just keeping an eye on how it is progressing.
> --
> Joe Cooper <[EMAIL PROTECTED]>
> http://www.swelltech.com
> Web Caching Appliances and Support
>
> =====================================================================
> If you would like to unsubscribe from this list send message to
> [EMAIL PROTECTED] with "unsubscribe oops-eng" in message body.
> Archive is accessible on http://lists.paco.net/oops-eng/
>
=====================================================================
If you would like to unsubscribe from this list send message to
[EMAIL PROTECTED] with "unsubscribe oops-eng" in message body.
Archive is accessible on http://lists.paco.net/oops-eng/
