Re: SMP scalability goal

A few points.

* 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.

* 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.

* Disk/ACL processing notwithstanding, scalability is going to depend a lot on
  transaction rates - ie, contention isn't a %age overhead imposed; it shows up
  in increasing transaction rates. Squid's transaction rates make good SMP gains
  easy if you know what you're doing, but scaling to >4 cores at high transaction
  rates difficult.

This is why my Cacheboy stuff has a medium term goal to tidy up a lot of the
codebase before I think about SMP. You'll find "SMP" will be helped by threading
some of the CPU intensive stuff (like some of the ACL processing) and I'll
probably do that in the short term, but properly parallelising the rest of the
codebase is a much bigger task than I think you realise..

Adrian

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).
>

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -