Open Stack

this seems to be pretty low, do you have memcaching enabled?

On Tue, Mar 26, 2013 at 4:20 PM, David Kranz <david.kranz at qrclab.com> wrote:
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev