openstack team mailing list archive

[Yun Mao <yunmao@xxxxxxxxx>]

Got it. Thanks,

If I read your number correctly, there are 10 db api calls, with total
time 0.388 seconds.

This is certainly not lightning fast. But it's not really slow, given
that the user is expecting to have the VM created in more than 10
seconds. <0.5 s latency is tolerable. If most of the time is spent in
network to db, then I'd say when we scale up a lot in compute/vm
numbers, the latency won't increase much.

One thing to note is that right now the DB APIs are all blocking
calls. So it could be tricky to get the performance number right when
measuring multiple concurrent requests.

Yun

On Fri, Mar 23, 2012 at 6:47 PM, Mark Washenberger
<mark.washenberger@xxxxxxxxxxxxx> wrote:
> Yun,
>
> I was working with a very small but fairly realistic setup. In this
> case I had only 3 Xen hosts, no more than 10 nova vms up at a time.
> And the environment was very nearly "fresh" so I believe the db
> tables were as small as they could be. I believe the utilization
> across the board in my setup was very low, and indeed the numbers
> were very consistent (I ran a large number of times, but didn't
> save all of the data :-(). Also, there were only 2 compute nodes
> running, but as the workflow only had rpc casts, I'm not sure that
> really mattered very much.
>
> The profile I gave was for vm creation. But I also ran tests for
> deletion, listing, and showing vms in the OS API.
>
> Networks were static throughout the process. Volumes were absent.
>
> "Yun Mao" <yunmao@xxxxxxxxx> said:
>
>> Hi Mark,
>>
>> what workload and what setup do you have while you are profiling? e.g.
>> how many compute nodes do you have, how many VMs do you have, are you
>> creating/destroying/migrating VMs, volumes, networks?
>>
>> Thanks,
>>
>> Yun
>>
>> On Fri, Mar 23, 2012 at 4:26 PM, Mark Washenberger
>> <mark.washenberger@xxxxxxxxxxxxx> wrote:
>>>
>>>
>>> "Johannes Erdfelt" <johannes@xxxxxxxxxxx> said:
>>>
>>>>
>>>> MySQL isn't exactly slow and Nova doesn't have particularly large
>>>> tables. It looks like the slowness is coming from the network and how
>>>> many queries are being made.
>>>>
>>>> Avoiding joins would mean even more queries, which looks like it would
>>>> slow it down even further.
>>>>
>>>
>>> This is exactly what I saw in my profiling. More complex queries did
>>> still seem to take longer than less complex ones, but it was a second
>>> order effect compared to the overall volume of queries.
>>>
>>> I'm not sure that network was the culprit though, since my ping
>>> roundtrip time was small relative to the wall time I measured for each
>>> nova.db.api call.
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp