There was recently a question in VMware vSphere Web Service SDK forum regarding gzip compression in vSphere API. I understand where the user came from – some of the SOAP responses could be pretty big. If they can be compressed, performance could be improved and network bandwidth reduced.
The case can be a little tricky. On one hand, compressing big data definitely saves bandwidth; on the other hand, it puts more workload on both the server and the client. Whether it improves performance in the end depends on the size of data. If it’s small enough to be held within one or several packets, it may not give you any noticeable difference. However, when the data is big, you may significantly reduce the time on transferring it, therefore reduces the overall processing time. After all, the network is more likely to be a bottleneck than CPU in general.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
On vCenter side, it uses Tomcat as the server for accepting vSphere API calls. You can turn on and off the compression in the connector part of the server.xml. For example, the following connector is turned on with compression.
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" compression = "on" compressableMimeType="text/html,text/xml,text/plain" compressionMinSize="1024"/>
Note that even the compression is turned on at the server, it’s used only when a client asks for it in the HTTP requests.
By default, the compression is NOT turned on with vCenter (check out the C:\Program Files\VMware\Infrastructure\tomcat\conf\server.xml file at your vCenter installation). It makes sense because most of the API calls return relatively small data. With compression turning on, it could hurt the scalability to support multiple clients.
Some of the API calls may return big response data, for example, performance stats. In the performance case, you can “compress” the responses in a different way. Instead of using the normal format which includes verbose XML tags, you can use csv format as described in Top 10 vSphere SDK best practices.
BTW, I found a pretty article discussing compressing XML which may result higher ratio. Unlike general compression like gzip, it accounts the unique characteristics of XML. Check it out here at IBM DeveloperWorks.