View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001371||bareos-core||[All Projects] configuration gui||public||2021-07-20 09:27||2021-09-09 09:11|
|Fixed in Version|
|Summary||0001371: Backup GUI awfully slow when used over TCP/IP remotely|
We have created a new setup where we'll use 1 GUI for multiple directors. Because of this the GUI runs on another system than the director itself. This is not a local lan but over internet (Gigabit tough)
We noticed a lot of actions are crazy slow, like loading the main dashboard , but also browing the the "jobs > Run" etc.
Maybe some socket options have to be set in order to have better performance?
See conclusions there, but there are many other settings possible like SO_KEEPALIVE to make sure connections keeps open and maybe others?
Maybe some API calls/requests should be grouped more as well?
Anyone else experienced this before? Or is everyone using the GUI on the same server as the director.
|Tags||No tags attached.|
Thanks for your report
Would you mind to share some computed real number (aka using the dev console for example). As "slow" express more a feeling than something tangible ;-)
Also some metrics (iperf, and so) between the console host and the differents directors
is NAT in use ?
Did you also tried to activate and use http/2 for serving the webpage. did it make any changes for you ?
Hi we use http/2 by default.
I think certain requests require a lot of "small" api calls. For example going to Jobs > Run is exceptionally slow compared to some other pages.
Can't you share some numbers ?
As you certainly see, loading the dashboard, is preloading all combo-list. of course this can vary depending of the number of items the api has to load.
having numbers could help us to reproduce or at least understand in which situation the symptom you described are seen.
opening the developer console on your browser (normally F12). tab network and pick number from there. report here will help you and us.
|There is not much too see in the console, it's the call to the run https://xxx/job/run/ which takes over 4 seconds for example. It must be in the api calls it makes underlying, it's not the resources :)|