On Fri, Feb 28, 2020 at 6:34 AM Manoj Patil <[email protected]> wrote:
> Dear Mike, > > Today we have measured bandwidth utilization using another verified tool > on our server and had below observations : > > 1. It seems that whenever *single *user session is in idle mode (No > screen change) , the bandwidth utilization is almost 707 B/s (which is low) > OK. > 2. And whenever *single * session is active(means Screen changes with > user inputs) , the bandwidth utilization is almost 30-40 KB/s which is too > high for us for single user session. > That may be too high for the amount of bandwidth you've allocated (50 Mbps) for 600 concurrent connections, but it is not too high nor unexpected for a single session. For an active session, this is low bandwidth. Multiplied by 600, it is beyond what will fit in what you've allocated, but this is not an issue with Guacamole; you have simply allocated way too few network resources for what is a very large load. >From these observations, We might say that whenever screen changes on > remote session, frames for whole screen are transferred every time over n/w > and hence causes high data flow which leads to high bandwidth utilization. > (This also happens whenever same screen/window is opened repeatedly). > No. Guacamole does not send the whole screen each time something changes. It sends only the changes. As mentioned earlier, if you want to see what Guacamole is sending, you need to capture a screen recording. The only case where Guacamole will send the entire screen is if the entire screen has changed. FYR i have attached screen shots for single user session in both idle and > active state. > > Urging you to check the same and guide us further to work on frames > transferred over n/w and how to tune it ? > I don't believe there is anything to be tuned on the Guacamole side. My expectation is that a screen recording would show that only the changed regions are being sent, and that the most appropriate compression is being used for those regions. On your network, if you intend to support 600 concurrent connections, you really need to allocate more than a single 50 Mbps line. As resource consumption will be bursty, not constant, you can likely get away with less than simply multiplying the bandwidth of an average connection by 600, but 50 Mbps is just not realistic. - Mike
