Open Stack

On Thu, Feb 6, 2014 at 10:34 PM, Joshua Harlow <harlowja at yahoo-inc.com>wrote:

>  Its a good question, I see openstack as mostly like the following 2
> groups of applications.
>
>  Group 1:
>
>  API entrypoints using [apache/nginx]+wsgi (nova-api, glance-api…)
>
>  In this group we can just let the underlying framework/app deal with the
> scaling and just use native wsgi as it was intended. Scale more
> [apache/nginx] if u need more requests per second. For any kind of long
> term work these apps should be dropping all work to be done on a MQ and
> letting someone pick that work up to be finished in some future time.
>

They should and from what I see they do. API services either provide some
work to workers or do some DB work, nothing more.


> Group 2:
>
>  Workers that pick things up off MQ. In this area we are allowed to be a
> little more different and change as we want, but it seems like the simple
> approach we have been doing is the daemon model (forking N child worker
> processes). We've also added eventlet in these children (so it becomes more
> like NxM where M is the number of greenthreads). For the usages where
> workers are used has it been beneficial to add those M greenthreads? If we
> just scaled out more N (processes) how bad would it be? (I don't have the
> answers here actually, but it does make you wonder why we couldn't just
> eliminate eventlet/asyncio altogether and just use more N processes).
>

If you really want greenthreads within your worker processes, you can use
"greenable" server for it. For example Gunicorn can work with eventlet,
uWSGI has its uGreen. Btw, you don't have to import eventlet every time you
need to spawn a thread or sleep a bit - you can just monkey-patch world
 (like almost everybody using eventlet in OpenStack do) if and when you
actually need it.

-- 

Kind regards, Yuriy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140206/1062a95b/attachment.html>