[OPEN-ILS-DEV] Server loads (theoretically)

[Mike Rylander]

On 10/13/07, Bill Ott <bott at grpl.org> wrote:
>
> Should Evergreen run more efficiently with more application servers, or
> more processor power?

That's a loaded question... :)

There is a trade-off to be made between reliability (more servers --
less concentrated points of failure) and ease of management (manage
one box instead of 10).

In most cases, in fact all cases that I can think of, more inexpensive
boxes will be better than one, or a very small number, of much larger
boxes.  You win both in terms of risk mitigation (losing one small box
in a big cluster is no big deal) and in terms of cost (should be much
less expensive).  Of course, now you're managing more machines ...

And that equation changes a bit when you consider virtualization,
which I'll explain below.

>
> I've got several blade servers running a test cluster (much prettier
> than my franken-cluster of months gone by).  I'm running one virtual
> brick (VMware w/ one OSRF router/gateway & 3 application servers) along
> with individual EG servers on other blades.  What I lack is enough test
> traffic to make a dent in the processing power (dual quad-core Xeons
> with 8GB RAM).
>

heh ... You'll be hard pressed to simulate a load that /would/ push
those procs hard.  A blade setup is just about ideal for an
OpenSRF/Evergreen cluster.

>  From an architectural perspective, once I get some real world load,
> should I see better performance running the OS natively and having more
> raw horsepower, or having ump-teen application servers available?
>

If it's a choice between fewer native (bare-metal) boxes and a huge
pile of virtualized servers, I'd go with the native every time for a
single-instance cluster.  You remove the CPU overhead of
virtualization, you remove any potential virtualiztion-caused bugs
(we've seen at least one, we think), plus any virt-caused race
condition exasperation (we've seen that consistently, though the one
we see is non-critical), not to mention the increased network stack
overhead, memory consumption, etc.

Now, obviously, we aren't addressing the database server here --
that's a whole other ball of wax...  ;)

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com