CIM performance investigation

Jan Safranek jsafrane at redhat.com
Thu Sep 5 14:49:55 UTC 2013


On 09/05/2013 03:04 PM, Russell Doty wrote:
> On Thu, 2013-09-05 at 09:40 +0200, Jan Safranek wrote:
>> I tried to find out why our client scripts are so slow and I got quite
>> surprising results.
>>
>> With default lmishell and https:// through loopback, I can get ~5-10
>> complete requests+responses/sec.
>>
>> Bottleneck are:
>>
>> 1) lmishell - it did some unnecessary queries and it was promptly fixed
>> (http://reviewboard-openlmi.rhcloud.com/r/817/).
>>
>> 2) lmishell - it creates nice Python objects for everything and it takes
>> non-trivial amount of time (and memory), so I did my performance tests
>> with native pywbem. There is not much we can do about it, I can only
>> suggest to use lmishell for tasks, where performance is not that important.
> Jan, can you give us at least a rough estimate of lmishell performance?
> Are we talking about a factor of 2 performance difference? Factor of 10?
> Factor of 100?

pywbem is roughly 2x faster than lmishell

>> 3) sblim-cmpi-base, it's really badly written and forks *a lot* for each
>> request it gets, e.g. they compute amount of swap by calling
>> system("cat /proc/swaps | awk '{print $3;}' | sed 1d");
>>
> Ouch! How common are the really bad operations? Once per session, every
> call, depends on what you are doing?

It depends. Usually it influences only queries to Linux_ComputerSystem,
Linux_OperatingSystem  and Linux_UnixProcess, but as almost everything
in CIM has association to Linux_ComputerSystem, it may negatively impact
also other CIM requests to storage or account or network.

We need sblim-cmpi-base only to provide Linux_ComputerSystem object that
represent the actual managed system. I checked that Pegasus provides
PG_ComputerSystem, which we can use for the same purpose, we just need
to add some config files to our providers.

Jan


More information about the openlmi-devel mailing list