[Cubicweb] running the web frontend and cw backend as 2 separate processes on the same machine

Sylvain Thénault sylvain.thenault at logilab.fr
Fri Jun 11 15:19:33 CEST 2010

On 11 juin 14:08, Aurélien Campeas wrote:
> Le jeudi 10 juin 2010 à 20:31 +0200, Alexandre Fayolle a écrit :
> > Hello,

> > I  have a CW instance running on a 2 CPU computer. Because of the GIL, I 
> > cannot really benefit from the 2 CPUs. Since CubicWeb can be setup to run on 2 
> > computers, one running the web frontend and the other one running the CW 
> > server itself, I was wondering if it was possible to use a similar setup, on a 
> > single machine, and if so, how would this be set up. I don't expect a x2 perf 
> > improvement, but even 20% would be good news. 
> > 
> > If this is not supported, maybe it could be considered, since multi core 
> > computers are common these days. I'm pretty sure something can be done with 
> > some environment variable hacking, which I could probably use to see the 
> > status of the GIL contention  vs. pyro call overhead tradeof. 
> > 
> > What do you think?

It's supported. Create one instance with config=repository, another one with
config=twisted, the first one exposed as pyro object, the other one with
a proper pyro-instance-id refering to the first one.

I would be curious to get some benchmarks w/ both configuration.
> I believe this should all be in the documentation.
> I'd like to extend your questions with the following: would it be
> complicated to have an all-in-one process handling web request & all
> short-lived requests + one repository process handling the long-running
> transactions (import/export, delete, clone) ?
> For better use of a 2-cores processor, this split could really be
> * 1 web front
> * 1 short-lived requests repo
> * 1 long transactions repo

This is far more tricky, and I don't see how you expect this kind of
thing to work... I don't think we want the web ui to deal with 2 distincts
repos. The only thing I can imagine is to have to all-in-one repo, with
a load balancer redirecting some urls to your 'long transactions instance'.
Though I'm afraid this won't be doable until we have persistent session
(else one instance doesn't know anything about session of the other
instance). Also that depends on things you may be doing in your hooks, 
telling if you can get multiple instances without problems.
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list