Hello again
So I've been working on this today and I want to qualify my response by saying I still don't have a repro on my side. File level access to our vCenter is not something I have, or can easily get, for the reasons given above. But I've been researching and testing against local HTTP servers and trying to reproduce the circumstances of the issue. My findings are that there may be two separate things at play here; a change that you can make on your side and a fix for a genuine issue on the Gateway side.
The background is that browsers talk to vCenter using HTTP/2, which handles file uploads very differently than HTTP/1. With HTTP/1, the browser opens a connection and sends the whole file in one continuous stream. Nothing interrupts it. With HTTP/2, the server hands out permissions in small allowances. It tells the browser "send me 64KB", the browser sends 64KB then waits for the server to say "another 64KB!" and so on. For a 100MB file, that's about 1600 back-and-forth exchanges instead of just 1. It works this way for good reason: it lets many request share a single connection, without any of them hogging it. But it also means an upload speed depends entirely on how quickly those exchanges complete.
(Side note that I used 64KB in my example because that is the default in the HTTP/2 specification, but this value is not fixed, it's chosen by the application and can indeed tune itself at runtime - if the application supports it. This is a fundamental difference to HTTP/1 where flow control is handled at the TCP level).
Through Gateway, each one of those exchanges simply has further to travel. Your machine to Gateway, Gateway to vCenter, and back again (and inside that there are many layers, the traffic is tunnelled over a local proxy and then web sockets).
Investigating this, I found that Gateway was likely adding up to 25ms of unnecessary delay in each exchange. It came from a batching optimization we made a couple of years ago that helped large continuous transfers but penalized this kind of back-and-forth traffic. I've made a fix for that and assuming it's accepted, will be in the next release. How much this helps you in reality I don't know, because the other factor affecting this is the overall RTT (round trip time). If your Gateway sits close to vCenter (a few ms RTT) it's possible our 25ms was the bulk of the penalty and the fix may bering Gateway uploads closer to direct speed. If there's real distance between Gateway and vCenter (say, 50ms), then the RTT is dominant and our fix will certainly help but it may not feel fast still.
In researching this I turned up this article . Broadcom documents raising vCenter's HTTP/2 upload allowance from 64KB to 8MB. That would take my 100MB example above from 1600 round trips to about a dozen, at which point extra distance stops mattering at all. It needs a config change on the appliance and a service restart, and I haven't tried or tested this myself. I'm going only from Broadcom's own documentation. If travel time is the dominant factor then this change is what will probably make uploads much faster.
That 64KB default has always been there, it just doesn't matter if you'r close enough to vCenter. It only becomes a bottleneck when each exchange has further to travel, which is what happens when the traffic is relayed by Gateway. So this isn't a misconfiguration in the current form, but it's a default that stops being suitable once the path gets longer.
Please, let me know if something isn't clear or you have other questions
Kind regards,
