Re: [Chicken-users] Enterprise and scalability

[Alaric Snell-Pym]

On 12 Jan 2009, at 12:20 pm, Mor Phir wrote:

> I was wondering if anyone on the ml where using chicken in a
> enterprise enviroment.

*booming silence*

I'm sure there was somebody!

> scenario:
> You wanna utilize more cores and more cpus at your setup, how would
> you go about this?

Well, just run more chicken processes. Design your app so that lots of
processes can cooperate.

For an HTTP server accessing read-only or database-held state, this is
easy: just run lots of http daemons and have a load balancing/failover
setup (eg, whackamole) in front.

Sharing state scalably is the hard part - and a problem I'm working on
solving for my day job, he he he.

But don't be put off by the lack of 'native threads' in Chicken. That
would let you use more cores in one chicken process, if you wrote
threads, but it can't scale beyond more than one physical server,
while being multi-process can; and threads sharing in-memory state are
a recipe for disaster (on the one hand, race conditions; on the other
hand, deadlocks or no actual concurrency since everything is
serialised around access to lock-protected structures).

Threads have their uses, but shoving lots of independent worker
threads into one process, rather than using them to gracefully ship
out parts of an operation so they can complete in parallel where
system resources allow, is dangerous!

As a case of useful threading, part of the system I'm working on for
work is a daemon that pulls messages from a multicast network and then
applies the writes described in those messages to a disk. Writes that
come in may overlap each other, often with a later write totally
overwriting an earlier one, and writes may come in big bursts, so we
have two 'threads': one that receives multicasts, unpacks them, and
inserts them into a queue of writes, checking for overlaps and dealing
with them there and then by discarding the obsoleted data, and another
that processes writes from the queue and actually does them on-disk.
One task is CPU-based, the other task is disk-based and involves a lot
of waiting for the disk to do its work, so they are allowed to run
independently (sadly, using asynchronous I/O isn't an option since the
disk writes go through a third-party library that works in an
inherently blocking way). However, because there is a precise master/
slave relationship between the two threads, it makes it a lot simpler
to make sure that shared state - the queue - is thread-safe. If we had
an arbitrary number of worker threads handling requests at once and
competing over access to the queue, it'd be a lot harder.

ABS

--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4