Re: benchmarking squid on solaris/x86

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Wed, 20 Mar 2002 18:25:31 +0200

On 20 Mar 2002, at 8:50, Duane Wessels <wessels@squid-cache.org> wrote:

> > For Sol7, you need kernel patch 105182-9 or better, and then set
> > in /etc/system:
>
> Sorry, forgot to mention I'm using Solaris 8.

> > Oh, make damn sure you use dlmalloc on solaris. Solaris' own
> > malloc is complete crap.
>
> This might be it. I put this down on my list of things to check.

 hmm, it is bad but I doubt it is that bad as to cause 2x
 performance slowdown in the face of plenty of ram...
 In fact, sun says its optimised for performance versus memory
 conservation.

> I doubt its any of the paging options since the process size
> is so small.

 then only "set tcp:tcp_conn_hash_size = 8192" can be of value.

> I don't want to tweak TCP stuff too much. Ideally I'd like all
> of the OSes to have similar TCP parameters as possible.

 I argue with such approach. Its not that ideal. TCP is integral
 part of kernel, and tuning kernel but rejecting tuning of TCP
 is not consistent.
 Using OS defaults makes obviously no sense. Picking arbitrary
 unified settings makes also little sense since different OSes
 implement different TCP options and get different hit while
 tweaking TCP params. In any case picked TCP params must have
 a good relation to reallife tunables. For very highperf cache
 you'd sometimes even have to resort to bending few standards.

 I know from experience that tcp_time_wait_interval and
 tcp_fin_wait_2_flush_interval impose performance hit on a
 Solaris system. I think on Linux too. By TCP it is required
 to keep TCP socket in timewait for pretty long time. This
 time is so long that when cache is servicing 200 tps it can
 build up thousands of sockets in timewait. Now Linux afaik
 handles this automatically by dropping oldest timewait sockets
 without a notice to keep their count decent, breaching standard,
 while solaris requires you to tune things manually, knowingly.
 So in the face of extreme loads you have to look into such
 matters anyway, otherwise you get a false feeling of comparing
 similar things.

 I'd try to squeeze max performance out of each OS by whatever
 means, then analyse what has an impact and how acceptable is
 required tweaking.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Wed Mar 20 2002 - 09:33:06 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:52 MST