Re: SMP scalability goal

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Thu, 24 Apr 2008 22:00:57 -0600

On Fri, 2008-04-25 at 11:49 +0800, Adrian Chadd wrote:

> * The single-core squid performance won't be the same as dual/quad core,
> so you can't assume that. I know this makes your assumptions difficult.
>
> * Basically, your single->dual core performance will generally expose
> the OSes parallelism for processing certain things, mostly network related.
> Start with "dualcore", as that begins to expose whats going on.
> FreeBSD, for example, will show decent single->dual core improvements for
> squid because the network if ithread(s) and TCP processing ithread (if
> enabled) will occur on different CPUs and squid doesn't generally push enough
> to saturate a single CPU worth of ithread processing. Yet.

My wording may have been poor. I assume we always use a quad box. Add
SMP support to Squid. Test Squid3 on that quad box with SMP disabled
(that is what I called single-core performance on a quad box). Test with
SMP enabled and configure Squid to use two (out of four) cores. Test
with SMP enabled and configure Squid to use three (out of four) cores.
This will give the 1-2 and 1-3 comparisons I was asking about.

What I would like to do now is to estimate the difference between those
future results. In other words, what kind of scale should we expect
after 5-10 months worth of work, very roughly?

> * Ok. Look at the performance of varnish, apache2-thread and memcached.
> memcached is a good one. They get reasonably linear performance up to quad
> core iirc where things like memory transaction rates impose limitations on
> performance.

Do you have any pointers to varnish, apache2-thread, or memcached
performance related to mutli-core scale?

Thank you,

Alex.

> On Thu, Apr 24, 2008, Alex Rousskov wrote:
> > Hello,
> >
> > I am drafting a SMP-scalability development contract for Squid3 and
> > need help defining scalability goals. We have 5-10 month for the first
> > SMP support implementation so it must be relatively straightforward,
> > with significant code reuse, but please note that this email is _not_
> > about the internal implementation design (threads, processes, shared
> > memory, etc). This is about black-box performance increase expectations
> > as far as scalability with multiple processors and cores is concerned.
> >
> > I believe I can narrow the questions further by considering specific and
> > likely scale points: Let's assume that single-core Squid performance on
> > a dual-core and quad-core boxes is roughly the same and let's limit
> > ourselves to a quad-core box. Let's assume that at least one core is
> > always dedicated for the OS and other non-Squid stuff.
> >
> > 1-2) How much faster should SMP-capable Squid perform when going from 1
> > core on a quad-core box to 2 cores on a quad-core box? 40%?
> >
> > 1-3) How much faster should SMP-capable Squid perform when going from 1
> > core on a quad-core box to 3 cores on a quad-core box? 100%?
> >
> > I tried to find good Apache or similar SMP scalability studies but
> > failed. Can anybody point me in the right direction? Somebody must have
> > done this already for Apache httpd!
> >
> > I do not think it is realistic to expect nearly linear scale (close to
> > 100% and 200% increase in performance), especially for the first
> > implementation.
> >
> > I wonder if expecting 40% speedup for 1-2 and 100% speedup for 1-3 is a
> > reasonable goal for the first implementation? These are ballpark
> > estimates, of course.
> >
> > Thank you,
> >
> > Alex.
> > P.S. My 40% and 100% estimates are based on a simple conservative model
> > that assumes 20% locking overhead (e.g., access to globals) and 10-20%
> > job scheduling overhead (e.g., sending an accepted FD to another
> > thread).
Received on Fri Apr 25 2008 - 04:02:05 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 30 2008 - 12:00:07 MDT