From: Francis Cianfrocca <garbagecat10@...>
Date: 2007-10-12T18:42:15+09:00
Subject: Re: Inter-Process Messaging

------=_Part_26789_16743290.1192182132137
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/12/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
>
> Francis Cianfrocca wrote:
> > What no one has yet asked you is: what kind of data do you have to pass
> > between this fork-parent and child, and by what protocol?
> >
> > Are they simple commands and responses (as in HTTP)? Is there a
> > state-machine (as in SMTP)? Or is the data-transfer full-duplex without
> a
> > protocol?
>
> Keeping in mind that this project is mainly intended as a learning
> experience, my specific idea is a http server architecture with
> generalist and specialist worker processes. The dispatcher would
> partition requests to generalists (as in HTTP) who in turn might
> dispatch to specialists (as in SMTP) for particular sub-tasks.
>
> Simple example: 100 requests for a thumbnail come at the same time, are
> split among N generalist workers, each of which asks the thumbnail
> specialist process to generate the thumbnail. The specialist catches the
> 100 simultaneous requests, generates the thumbnail *once* and sends the
> result back to the N generalists, who render it.
>
> > Are the data-flows extremely large? Exactly what are your performance
> > requirements?
>
> Good questions, but ultimately my true purpose is to educate myself
> about parallel processing; that's the only requirement I have. So while
> I'd say data-flows are unlikely to be large in this case, I'd still like
> to how to handle large data-flows.
>
> Hmmm, any good books to recommend?
>
>
>

Sounds like you've already read all the books you need to read. You have the
standard lingo down pat!

I'm probably the wrong person to ask, because I've been doing
high-performance parallel processing for many, many years, and my advice
(being experience-based) will assuredly fly in the face of orthodoxy.

But here goes: you picked the wrong project to demonstrate parallel
processing. Fast handling of network I/O is best done in an event-driven
way, and not in parallel. The parallelism that this problem exhibits arises
from the inherent nondeterminacy of having many independent clients
operating simultaneously. This pattern does expose capturable intramachine
latencies, but they're due to timing differentials, not to processing
inter-dependencies.

It's intuitively attractive to structure a network server as a set of
parallel processes or threads, but it doesn't add anything in terms of
performance or scalability. As regards multicore architectures, they add
little to a network server because the size of the incoming network pipe
typically dominates processor bandwidth in such applications.

You may rejoin: "but how about an HTTP server that does a massive amount of
local processing to fulfill each request?" Now that's more interesting. Just
get rid of the HTTP part and concentrate on how to parallelize the
processing. That's a huge and well-studied problem in itself, and the net is
full of good resources on it.

------=_Part_26789_16743290.1192182132137--