Re: Multi-threaded Performance Pitfalls presentation

ciaran.mchale@xxxxxxxx ha scritto:
Hi folks,


I *think* that my analysis in the presentation is correct, but some of
it is educated guesswork as I found it very difficult to get concrete
information from Google searches that would confirm or refute my
analysis.


To me looks pretty good (if you're talking to non-experts and trying to
explain them what happened), but there is a basic mistake.

Binding a process with a CPU means binding all its threads with that
CPU, thus preventing each one of those threads to run concurrently.

In that scenario, (roughly, but see more later on) any single thread
program written correctly, that is, managing resources through
non-blocking system services, will outperform any MT program. The only
thing that you "gain" with MT is, theoretically, time wasted in context
switches and cache flushes.

At a finer level of analysis, a well designed MT program may be worthy
also on a single-cpu environment when threads are designed to exploit
system resources latencies; network vs. disks vs. memory transfers can
be handled by different threads, punching in when the system can serve
them with on-line resources. You'll get context switches each time, but
they may well be buried down in pauses that wouldn't be productive for
the CPU anyhow.

In that scenario, threading can be also used efficiently to perform
"overall" tasks, as periodic controls, memory pool cleaning, monitoring
sampling and so on. Correct timings of those "out-of-band" tasks can be
a bit difficult to code in a single-thread application, and "difficult"
can mean ugly, inefficient and unmaintainable code. An equivalent MT
program may perform better, or at least be preferable for clarity and
maintainability.

Said this, it's clear that your sample couldn't fall in this categories;
the description is sparse, but it seems that the server just spreads a
new thread to manage a request, or uses a pre-launched thread to
"consume" a request.

A rule of thumb is that to allocate a thread for each CPU you have free
(considering also other software that may run on a machine), pondered by
the idle time each thread is usually subject to during its processing.
I.e., if your tasks are CPU intensive and you run on an 8-CPU machine, 8
threads should give you the best overall performance. If you have idle
times for about 50% of the time, then 16 threads may give you a better
performance. Of course, this "depends" on a lot of things, but that's a
good starting point to start thinking about consumer thread pools.

Also, threads working as agents on physical resources are usually
performing better when they are in the number of one per resource. I.e.
one receiver/transmitter thread per network interface. You can't
physically read or write two packets on the same interface at the same
time; if you try, one of the two threads will have to wait. Again, that
may depend on the complexity you need for the
single-thread-per-interface implementation. If it is complex for the
threads in the application to deliver data to a single thread managing
I/O (or to receive data from it), then this complexity may mean time and
memory (and code elegance, that is, maintainability), and again you may
find out that you're better to pay context switches and waits on the
contended resources than dealing with that complexity.

Long story short: if an MT server runs better when bound to a single
CPU, then there's a long lasting and worthy job for an MT consultant,
and a LOT of code to be rewritten from ground up.

Giancarlo Niccolai.

.

Relevant Pages

  • Re: Mainframe Applications and Records Keeping?
    ... Sharing memory resource is not true. ... Memory can be easily reconfigured, but, assuming 24x7 availability it is big advantage. ... Even If sharing resources could make some savings in term of megabutes or CPU cycles, it doesn't necessarily mean any savings in costs. ...
    (bit.listserv.ibm-main)
  • Re: headers sent issue
    ... huge waste of resources, cpu & memory. ... You are using memory for buffering that hypothetically could be needed ... will keep the use of memory & CPU to a minimum. ... start session ...
    (comp.lang.php)
  • Re: headers sent issue
    ... huge waste of resources, cpu & memory. ... You are using memory for buffering that hypothetically could be needed ... will keep the use of memory & CPU to a minimum. ... start session ...
    (comp.lang.php)
  • Re: A good software firewall
    ... > Can anyone advise me a good software firewall, which does not use a lot of ... > resources, including CPU and memory, and is also fast? ...
    (comp.security.firewalls)
  • Re: What Delphi users really want (other than bugfixes)
    ... then it's only a waste of CPU and memory ... > resources. ... Take a look at what Free does in Delphi for .Net. ...
    (borland.public.delphi.non-technical)