Description of problem: when scanning a large scale list without compress can be found long response time. when compress=True we got much faster response time see the comparison: compress False list size cap 100 response time 4.50143885612 list size cap 300 response time 11.0167760849 list size cap 500 response time 27.9535710812 compress True list size cap 100 response time 2.03919100761 list size cap 300 response time 1.44519710541 list size cap 500 response time 2.07873082161 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. api.system_service().hosts_service().list(max=x amount of objects) 2. 3. Actual results: compress not enabled by default Expected results: compress should be enabled by default Additional info:
juan - what is the status of compression in the new Ruby gem, which the new provider in CFME uses? Can this speed up initial inventory fetch? Any downside to this being the default? (higher CPU usage on the client? not sure it's an issue).
Compression is also supported in the Ruby SDK, but it isn't enabled by default. Enabling it is a matter of adding the "compress=True" parameter (in Python) or ":compress => true" parameter (in Ruby). In the CFME provider compression isn't enabled: https://github.com/ManageIQ/manageiq/blob/master/app/models/manageiq/providers/redhat/infra_manager.rb#L65 Enabling it could speed up initial inventory fetch, but I guess that not a lot, as most of the time is due to the multiple network round-trips between ManageIQ and oVirt. I don't have numbers to back this statement. CPU usage is a downside, but probably not the most important. I believe that the most important downside is debugging. If compression is enabled then the debug messages (if debug is enabled) contain the compressed output (this is how libcurl works) which makes them almost useless. As debugging isn't enabled by default in ManageIQ I think we can enable compression. We should probably also add configuration parameters so that the ManageIQ user/developer can enable/disable both debugging and compression.
Targeting to 4.1 for now, if needed we can backport to 4.0.z (in that we case we would need separate bugs for each SDK).
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.
verified on top of sdk 4.1: -=>>python /usr/lib64/python2.7/site-packages/ovirtsdk4/version.py 4.1.0a0 when ignore the compress flag when creating the api object: list size cap 10 response time 1.23655796051 list size cap 300 response time 1.87913990021 list size cap 500 response time 2.52585601807