High latency / low bandwidth optimizations Universal GUI
We are currently testing the cloud-hosted Universal GUI on a few of our vessels. At sea they use VSAT internet, which is famously known for having high latency / low bandwidth.
I am wondering what kind of configuration possibilities are available on the platform to optimize the performance in this situation as much as possible?
A few specific issues that we encounter:
On loading the Universal GUI the first time, even before login a shocking 86.8 MB of data is added to the Cache storage. What can we do to significantly reduce this amount of data?
On loading the Universal GUI the browser could time-out. What could we do with our Indicium/IIS settings to make the browser wait longer for a response?
On Commit we get a snackbar error that says ‘It took more than 10000ms to send all updates to Indicium.’ and the Commit is cancelled. Is it possible to increase this value somehow?
Any other recommendations, be it for the Infrastructure or configuration in the SF, are also highly appreciated!
Page 1 / 1
Hi Arie,
Interesting question and I have some questions about your requirements. (I do not have an answer for your other questions right now).
About your findings for the "Cache storage", I don't think you should look at that data - at least, not from a network perspective. The network tab shows more interesting data. For me, when I check TCP I have 108 requests with 14.2MB of data (without logging in). This should be similar for you, and not the 86MB the cache storage is showing. I validated this with Wireshark as well, which shows a similar amount of data. That being said, the 14MB is still a lot over VSAT. (Note, if it is more for you, can you check if gzip is configured correctly?)
I was wondering, do you use the barcode scanner? This is preloaded automatically and is around 2.5MB - which is a lot if you don't need it. You cannot prevent this at the moment.
The same applies for the HTML editor (350KB), is this something you need in the application?
I do not know if we can easily prevent the preloading of the options above, but it might be a pretty big win if we can do something about it.
Another option might be choosing a different hosting model. Something like a caching server on the vessels. If you have 10 clients on your vessel, and each client is loading the Universal GUI from the Cloud it might be a bit painful (performance but also from a money perspective). Also, it is a bit unnecessary because the files are static anyway.
I do not have experience with this kind of software though, but at least for the first part of your question this sounds like a potential option.
@Dick van den Brink Thanks for your response and your questions, let's hope we're getting some answers too :)
First of all, we realized we hadn't whitelisted the new URL yet, so currently gzip is indeed not working. That will indeed make quite a difference.
We don't use the Barcode scanner at the moment, so not having that pre-loaded would be a great win
We don't use the HTML editor on the vessels at the moment, so that would also help indeed
We'll investigate the various options between fully cloud-hosted and fully vessel-hosted the coming period. I really hope we can stay away from fully vessel-hosted and having to build synchronization logic, but the Universal GUI does not give us much leeway at the moment. So any additional configuration options would be very much appreciated!
A caching mechanism on board would be interesting middle-ground in terms of infrastructure, but as far as I know it is also a relatively expensive and complicated solution.
@Dick van den Brink Update: we had to update some Compression settings in IIS on the webserver, as well as whitelist the relevant URLs in our antivirus, but now we indeed have a similar compression as you reported for TCP. That’ll definitely help quite a bit.
Hello @Arie V,
It could be worthwhile to have a look at Brotli compression as well. Brotli compression can result in much less data than gzip compression and it will also be faster than gzip for the same level of compression. On slow connections this can make a big difference.
Hi Arie,
I checked the code and the ‘It took more than 10000ms to send all updates to Indicium’ message is a hardcoded limit in the Universal GUI at the moment. So there is currently no way to configure it.
There are some more locations with that type of timeout in the code base that needs to be checked/changed.
@Vincent Doppenberg@Dick van den Brink Thanks for your feedback and suggestions!
We'll definitely have a look at the Brotli compression!
As for the 10.000ms limit: I discussed this with @Anne Buit too and we concluded that users having to wait 10 seconds is the main problem, increasing the limit is perhaps not the solution they would be looking for…
On removing the Barcode scanner / HTML editor, are these packed in specific js chuncks that we could recognize and remove from the Universal GUI zip?
On caching: the biggest challenge in our case is the fact that loading a new Universal GUI version or a new Application version happens upon login of a user. It would be great if a new GUI version or Application version would be pushed to the cache of a user in the background automatically. This would avoid the bottleneck at login. See my last comment below this Idea, any chance that this is picked up soon?
We are testing with Brotli compression and the initial results are promising! Indeed a 90% compression on loading the Universal GUI for the first time:
