performance issue retrieveServiceContent() API call

[davkul]

I have found that this call is taking about 11 seconds in the program that I have written that is retieving performance data from the ESX Server.

Here's a code snippet (cobbled together from separate methods) ...

protected ServiceContent m_svcCont = null;

protected VimPortType m_webService = null;

protected ServiceContent m_svcCont = null;

m_svcInst = new ManagedObjectReference();

m_svcInst.setType("ServiceInstance");

m_svcInst.set_value("ServiceInstance");

m_locator = new VimServiceLocator();

m_locator.setMaintainSession(true);

m_webService = m_locator.getVimPort(new URL(urlStr));

m_svcCont = m_webService.retrieveServiceContent(m_svcInst);

To try to figure out what the issue was, I instrumented the retrieveServiceContent method that was generated

from the WSDL with getting timestamp to pinpoint where the time was being spent. What's happening is that org.apache.axis.client.Call.registerTypeMapping() is getting called 1672 times. For every VI SDK API call

there's a pair of calls to registerTypeMapping() for the repsonse and request and others as well. This gets

done for the first call to the Web Service as there's a flag in the code checking for the first call.

What I'm wondering is if anyone else has noticed the slowness of the first call out to the web service? Is

this just an accepted and well-known overhead of communicating with a web service? My application can't

cache the connection to the web service so every time I have to get performance or configuration data

for the ESX Server and the VMs, I hit this big overhead. Has anyone looked into this before?

Thanks.

Dave

[akutz]

This is certainly an issue with .NET due to some broke-a** serialization, but it has largely been fixed. Java 1.5 (5) faces a similar issue. Although the following KB is referenced along side the previous version of the VI3 SDK, it is a Java 5 issue, not a VMware SDK issue, and therefore if you have an given version of Java, you will likely still be subject to the mentioned slowdown: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=2983901.

[davkul]

akutz,

Thanks for your reply, but I had already come across that KB article awhile back and rerunning with a later version of Java didn't make any difference. This seems to be purely due to the number of registerTypeMapping() calls that are done (1652 of them). I'm just surprised that there hasn't been more people raising this as an issue. Maybe most applications that use the VI SDK reuse the connection and just take that initial hit as a start up cost, where my application can't cache/reuse the connection.

[akutz]

With .NET people certainly take the hit. However, as I said, I have not had any performance issues. Axis sure is a pain sometimes. Ever trying using log4j with it? Apache doesn't turn their own logging down by default so a default log collector gets all of the DEBUG info from Axis. Ugly.

Anyway, I have code that does what you do, and I am comparing yours and mine and not seeing a big difference. May I please ask what URL you are using? Or at least the format. Also, are you turning off SSL checking (using a fake factory) or are you using a keystore?

[davkul]

I'm using a keystore and the URL is https://<fully-qualified machine name>/sdk. Would this matter? I assumed that the registerTypeMapping() call isn't going out to the web service, but the logic behind it is just running on the client.

And, by the way, do you have more information on using a fake factory? Does this mean that the ESX Server can still be configured to use https (which is the default) and you don't have to supply the client with the location of a keystore file with the cert for that ESX Server in it?

[vmware_student]

Hi,

I have been facing a similar issue where the first connection to the web service takes around 1 and a half minute, When i debug the program, it takes around 20 secs. The specific call that takes time is:

service.retrieveServiceContent(serviceRef);

Please can anybody help me with this. What could be the reason behind this kind of a behavior or is it an expected behavior?

Thanks

[TealHaze]

I too am having performance issues with RetrieveServiceContent( ).

To ensure it wasn't something in my code, I went back to the VI-SDK 4.0 samples and built the SimpleClient application with a modification to use a strong name key when building the VimSrv DLLs and SimpleClient EXE. From my experimenting, I'm not seeing a performance issue when calling the application from my laptop installed with Windows XP SP2 and .NET 3.5, but when taking that same SimpleClient application to a Windows Server 2003 (32-bit) or Windows Server 2008 (64-bit) system, the application is very slow and placing timers in the code I can see that it's spending a lot of time in the RetreiveServiceContent call as well as other pieces of code.

I know there's a lot of differences between my laptop machine with Windows XP and my server versions, but I do not understand what could cause the performance issue. When it runs on the server platforms, the application allocates close to 400 MB of memory which it eventually relinquishes down to 20 MB, but this huge memory hogging step is occurring after the ServerCertificateValidationCallback phase.

It makes me wonder if the .NET versions installed on Windows XP really is the same as .NET on Windows Server 2003 (32-bit).

C:\simpleClient&gt;SimpleClient2.exe root Passw0rd

2:56:53 PM ===&gt; ServerCertificateValidationCallback setting ServiceInstance;

2:56:53 PM - ENTERING Connect!!!!

2:56:57 PM ===&gt; service.RetrieveServiceContent(_svcRef);

2:57:23 PM ===&gt; ServerCertificateValidationCallback returning TRUE;

2:57:34 PM ===&gt; s_sic.propertyCollector;

2:57:34 PM ===&gt; _sic.rootFolder;

2:57:48 PM Object Type : Folder

2:57:48 PM Reference Value : ha-folder-vm

Property Name : name

Property Value : vm

2:57:48 PM Object Type : HostSystem

2:57:48 PM Reference Value : ha-host

Property Name : name

yada yada yada yada

2:57:49 PM : Press enter to exit

If anyone has more insight on resolving these performance issues, please share. Thanks.

[netlib]

> a modification to use a strong name key when building the VimSrv DLLs

Don't know if this thread is still monitored, but can you tell us how you rebuilt the VimSrv DLLs using Strong Names? I downloaded the WebSdk but cannot see how to modify the VimSrv DLL projects as they don't appear to be standard C# projects.

I need to assign Strong Names to files like vimservice2008.dll, etc, in order to use them by multiple programs without duplicating the dlls in each program directory.

Thanks.