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."
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
