------art_27085_21879431.1192195415888
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:
>
>
> Could you elaborate what you mean by "timing differentials" and
> "processing inter-dependencies"? For regular webapps, time spent
> querying the database most certainly exposes capturable intramachine
> latencies. Event-driven sounds good, but doesn't that requires that
> *all* I/O be non-blocking? If you have blocking I/O in, say, a
> third-party lib, you're toast.


Event-driven application frameworks often deal with library calls that
necessarily involve blocking network or intramachine I/O (DBMS calls being
the only really common example) by using a thread pool. For example,
EventMachine provides the #defer method to do this. It manages an internal
thread pool that runs outside of the main reactor loop.

In general, the problem of architecting a high-performance web server that
includes external dependencies like databases, legacy applications, SOAP,
message-queueing systems, etc etc, is a very big problem with no simple
answer. It's also been intensely studied, so there are resources for you all
over the web.


> You mean to say it's the network that is usually the bottleneck, not the
> CPU? Well, in my experience the database is usually the bottleneck, but
> let's not forget that ruby is particularly demanding on the CPU.


I made that remark in relation to efforts to make network servers run faster
by hosting them on multiprocessor or multicore machines. You'll usually find
that a single computer with one big network pipe attached to it won't be
able to process the I/O fast enough to keep all the cores busy. You might
then be tempted to host the DBMS on the same machine, but that's rarely a
good idea. Simpler is better.

While optimizing for CPU speed is fine, I'm also interested in process
> isolation. If you have a monster lib that takes 1 minute to initialize
> and requires 1 GB of resident memory but is used only occasionally, do
> you really want to load it in all of your worker processes?
>
>

You're assuming that worker processes are a good idea in the first place,
which I haven't granted :-). But seriously, if this is the road you want to
go down, then I'd recommend you look at message-queueing technologies. I'm
not in favor of distributed objects for a lot of reasons, but something like
DRb will give you the ability to avoid marshalling and unmarshalling data.
SOAP is another alternative, but having been there and done that, I'd rather
chew glass.

------art_27085_21879431.1192195415888--