Bug 1125123 - enable multiple keystone-all worker processes
Summary: enable multiple keystone-all worker processes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 5.0 (RHEL 7)
Hardware: All
OS: Linux
unspecified
high
Target Milestone: z1
: 5.0 (RHEL 7)
Assignee: Nathan Kinder
QA Contact: Udi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-31 05:51 UTC by Neependra Khare
Modified: 2016-04-26 14:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-21 17:18:50 UTC


Attachments (Terms of Use)

Description Neependra Khare 2014-07-31 05:51:53 UTC
Description of problem:

With commit#3580c2af1bd8a8c6574cf4cb7b63bd75b8effad7 in upstream, keystone now supports running multiple keystone-all worker processes. 

I have taken some performance numbers with Devstack with following scenarios:-
1. default keystone settings (single threaded keystone_all process) 
2. by setting public_workers=4 in keytone.conf file, which enable 4 keystone_all worker processes. 

with 2nd scenario performance I see ~4X performance gain. 

Additional info:
It looks upstream is now leaning towards running keystone under httpd
https://bugzilla.redhat.com/show_bug.cgi?id=1111274#c3

but having multiple threads of keystone_all increases the performance significantly. I would like to explore the possibility to back port that patch with RHEL-OSP5 until we don't default to run keystone inside httpd.

Comment 2 Nathan Kinder 2014-08-01 17:32:47 UTC
I would like for the changes to be proven out more upstream.  There were concerns by the Keystone team upstream that this change could expose some parallelism bugs.  These sorts of bugs would most likely be found in real deployment under heavy load as opposed to the gate tests.

This change is also something that would not be backported in Icehouse upstream, so we would have to carry this patch long term for RHEL OSP 5.  This is certainly possible, but it's not ideal.

Comment 4 Arthur Berezin 2014-08-21 17:18:50 UTC
We are also leaning towards defaulting to deploy Keystone under httpd in downstream via OSP-Installer.

I think we should close WONTFIX this BZ, given the maintenance effort needed for the backport throughout OSP5 life cycle, and that direction upstream.


Note You need to log in before you can comment on or make changes to this bug.