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.

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).

-Josh

From: Yuriy Taraday <yorik....@gmail.com<mailto:yorik....@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 6, 2014 at 10:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] Asynchrounous programming: replace eventlet with 
asyncio

Hello.


On Tue, Feb 4, 2014 at 5:38 PM, victor stinner 
<victor.stin...@enovance.com<mailto:victor.stin...@enovance.com>> wrote:
I would like to replace eventlet with asyncio in OpenStack for the asynchronous 
programming. The new asyncio module has a better design and is less "magical". 
It is now part of python 3.4 arguably becoming the de-facto standard for 
asynchronous programming in Python world.

I think that before doing this big move to yet another asynchronous framework 
we should ask the main question: Do we need it? Why do we actually need async 
framework inside our code?
There most likely is some historical reason why (almost) every OpenStack 
project runs every its process with eventlet hub, but I think we should 
reconsider this now when it's clear that we can't go forward with eventlet 
(because of py3k mostly) and we're going to put considerable amount of 
resources into switching to another async framework.

Let's take Nova for example.

There are two kinds of processes there: nova-api and others.

- nova-api process forks to a number of workers listening on one socket and 
running a single greenthread for each incoming request;
- other services (workers) constantly poll some queue and spawn a greenthread 
for each incoming request.

Both kinds to basically the same job: receive a request, run a handler in a 
greenthread. Sounds very much like a job for some application server that does 
just that and does it good.
If we remove all dependencies from eventlet or any other async framework, we 
would not only be able to write Python code without need to keep in mind that 
we're running in some reactor (that's why eventlet was chosen over Twisted 
IIRC), but we can also forget about all these frameworks altogether.

I suggest approach like this:
- for API services use dead-simple threaded WSGI server (we have one in the 
stdlib by the way - in wsgiref);
- for workers use simple threading-based oslo.messaging loop (it's on its way).

Of course, it won't be production-ready. Dumb threaded approach won't scale but 
we don't have to write our own scaling here. There are other tools around to do 
this: Apache httpd, Gunicorn, uWSGI, etc. And they will work better in 
production environment than any code we write because they are proven with time 
and on huge scales.

So once we want to go to production, we can deploy things this way for example:
- API services can be deployed within Apache server or any other HTTP server 
with WSGI backend (Keystone already can be deployed within Apache);
- workers can be deployed in any non-HTTP application server, uWSGI is a great 
example of one that can work in this mode.

With this approach we can leave the burden of process management, load 
balancing, etc. to the services that are really good at it.

What do you think about this?

--

Kind regards, Yuriy.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to