From r at erik.prutser.cx  Fri Jan  5 11:04:51 2007
From: r at erik.prutser.cx (Erik van Zijst)
Date: Fri, 05 Jan 2007 11:04:51 +0100
Subject: [Rd] How to execute R scripts simultaneously from
	multiple	threads
In-Reply-To: <459D46FD.2060307@vanderbilt.edu>
References: <459B6DBA.3050207@erik.prutser.cx>	<200701031337.45613.vdergachev@rcgardis.com>	<459CCEDB.5040201@erik.prutser.cx>
	<200701041237.30054.vdergachev@rcgardis.com>
	<459D46FD.2060307@vanderbilt.edu>
Message-ID: <459E22C3.3040801@erik.prutser.cx>

Jeffrey Horner wrote:
> I haven't looked at RServe in awhile, but I think that it fires up an R 
> interpreter in response to a client request and then sticks around for 
> the same client to serve it additional requests. The question is how 
> does it manage all the R interpreters with varying demand.
> 
> This issue is solved when you embed R into Apache (using the prefork 
> MPM), as the pool of apache child processes (each with their own R 
> interpreter) expands and contracts on demand. Using this with the 
> loopback device would be a nice solution:

We've looked at RApache as well. It offers a nice pooling solution quite 
in line with Apache's own runtime.
We'd certainly need pooling for our solution as we can't afford a fork 
for each evaluation. Luckily, as you mentioned already, this is fairly 
easy when using RServe as well. If you keep the connection to an 
R-process open, it stays alive. We'd do the actual pooling mechanism 
ourselves.

Erik
-- 
QOTD:
	"I'm on a seafood diet -- I see food and I eat it."



[Rd] How to execute R scripts simultaneously from multiple threads
Erik van Zijst