Open Stack

On Mon, 2 Apr 2018, Alex Schultz wrote:

> So this is/was valid. A few years back there was some perf tests done
> with various combinations of process/threads and for Keystone it was
> determined that threads should be 1 while you should adjust the
> process count (hence the bug). Now I guess the question is for every
> service what is the optimal configuration but I'm not sure there's
> anyone who's looking at this in the upstream for all the services.  In
> the puppet modules for consistency we applied a similar concept for
> all the services when they are deployed under apache.  It can be tuned
> as needed for each service but I don't think we have any great
> examples of perf numbers. It's really a YMMV thing. We ship a basic
> default that isn't crazy, but it's probably not optimal either.

Do you happen to recall if the trouble with keystone and threaded
web servers had anything to do with eventlet? Support for the
eventlet-based server was removed from keystone in Newton.

I've been doing some experiments with placement using multiple uwsgi
processes, each with multiple threads and it appears to be working
very well. Ideally all the OpenStack HTTP-based services would be
able to run effectively in that kind of setup. If they can't I'd
like to help make it possible.

In any case: processes 3, threads 1 for WSGIDaemonProcess for the
placement service for a deployment of any real size errs on the
side of too conservative and I hope we can make some adjustments
there.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent