Open Stack

Related to this, I measured that the rate at which keystone (running on 
a real fairly hefty server) can handle the requests coming from the 
auth_token middleware (no pki tokens) is about 16/s. That seems pretty 
low to me. Is there some other keystone performance problem here, or is 
that not surprising?

  -David

On 3/24/2013 9:11 PM, Jay Pipes wrote:
> Sure, you could do that, of course. Just like you could use gunicorn or
> some other web server. Just like you could deploy any of the other
> OpenStack services that way.
>
> It would just be nice if one could configure Keystone in the same manner
> that all the other OpenStack services are configured.
>
> -jay
>
> On 03/23/2013 01:19 PM, Joshua Harlow wrote:
>> See: https://github.com/openstack/keystone/tree/master/httpd
>>
>> For example...
>>
>> This lets apache do the multiprocess instead of how nova, glance ...
>> have basically recreated the same mechanism that apache has had for years.
>>
>> Sent from my really tiny device...
>>
>> On Mar 23, 2013, at 10:14 AM, "Joshua Harlow" <harlowja at yahoo-inc.com
>> <mailto:harlowja at yahoo-inc.com>> wrote:
>>
>>> Or I think u can run keystone in wsgi+apache easily, thus getting u the
>>> multiprocess support via apache worker processes.
>>>
>>> Sent from my really tiny
>>> device....
>>>
>>> On Mar 22, 2013, at 10:47 AM, "Jay Pipes" <jaypipes at gmail.com
>>> <mailto:jaypipes at gmail.com>>
>>> wrote:
>>>
>>>> Unfortunately, Keystone's WSGI server is only a single process,
>>> with a
>>>> greenthread pool. Unlike Glance, Nova, Cinder, and Swift, which all
>>> use
>>>> multi-process, greenthread-pool-per-process WSGI servers[1],
>>> Keystone
>>>> does it differently[2].
>>>>
>>>> There was a patchset[3] that added
>>> multiprocess support to Keystone, but
>>>> due to objections from termie and
>>> others about it not being necessary,
>>>> it died on the vine. Termie even
>>> noted that Keystone "was designed to be
>>>> run as multiple instances and load
>>> balanced over and [he felt] that
>>>> should be the preferred scaling point".
>>>>
>>>> Because the mysql client connection is C-based, calls to it will be
>>>>
>>> blocking operations on greenthreads within a single process, meaning
>>>> even
>>> if multiple greenthreads are spawned for those 200 incoming
>>>> requests, they
>>> will be processed synchronously.
>>>> The solution is for Keystone to
>>> implement the same multi-processed WSGI
>>>> worker stuff that is in the other
>>> OpenStack projects. Or, diverge from
>>>> the deployment solution of Nova,
>>> Glance, Cinder, and Swift, and manually
>>>> run multiple instances of
>>> keystone, as Termie suggests.
>>>> Best,
>>>> -jay
>>>>
>>>> [1] All pretty much
>>> derived from the original Swift code, with some Oslo
>>>> improvements around
>>> config
>>>> [2] Compare
>>>>
>>> https://github.com/openstack/glance/blob/master/glance/common/wsgi.py
>>> with
>>> https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py
>>> [3] https://review.openstack.org/#/c/7017/
>>>> On 03/21/2013 07:45 AM,
>>> Kanade, Rohan wrote:
>>>>> Hi,
>>>>>
>>>>> I was trying to create 200 users using
>>> the keystone client. All the
>>>>> users are unique and are created on separate
>>> threads which are started
>>>>> at the same time.
>>>>>
>>>>> keystone is handling
>>> each request synchronously , i.e. user 1 is
>>>>> created, then user 2 is
>>> created ...
>>>>> Shouldnt  keystone be running  a greenthread for each
>>> request and try to
>>>>> create these users asynchronously?
>>>>> like start
>>> creating user 1 , while handling that request, start creating
>>>>> user 2 or
>>> user n...
>>>>> I have attached the keystone service logs for further
>>> assistance.
>>>>> http://paste.openstack.org/show/34216/
>>>>>
>>>>>
>>> ______________________________________________________________________
>>> Disclaimer:This email and any attachments are sent in strictest
>>> confidence for the sole use of the addressee and may contain legally
>>> privileged, confidential, and proprietary data. If you are not the
>>> intended recipient, please advise the sender by replying promptly to
>>>>> this
>>> email and then delete and destroy this email and any attachments
>>>>> without
>>> any further use, copying or forwarding
>>>>>
>>>>>
>>> _______________________________________________
>>>>> OpenStack-dev mailing
>>> list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> <mailto:OpenStack-dev at lists.openstack.org>
>>>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> _______________________________________________
>>>> OpenStack-dev mailing
>>> list
>>>> OpenStack-dev at lists.openstack.org
>>>> <mailto:OpenStack-dev at lists.openstack.org>
>>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev