Dear, Thank For your appreciation .
The only thing that I noticed is that there is no compression between the server and the client. Meaning that full sized base64 encoded PNG images are send to the client, which causes a high network load. i am try to find out why more bandwidth is required for 600 connection and how to reduced it. My Observation is--- we observe that in my colleague company those people used Microsoft remote desktop Web client (using activex) for 1200 connection in 10 Mbps for huge transaction. and we used Xrdp+wine+Guacamole with 600 connection with 50 Mbps bandwidth . what protocol they are used ( Microsoft remote desktop Web client ) is taking less bandwidth compare with Guacamole. if we tune guacamole like that Microsoft remote desktop Web client it is valuable for all in low bandwidth. without your help we can not do any changes in guacamole server. Please guide. On Sun, 1 Mar 2020 at 11:36, Mike Jumper <[email protected]> wrote: > On Sat, Feb 29, 2020, 20:57 Manoj Patil <[email protected]> wrote: > >> Dear, >> >> Thanks your valuable replay . >> >> I observe that when data send from server to client in image/PNG and PNG >> take to much bandwidth rather than *Webp.* >> > > No, whether WebP performs better than PNG depends on the content of the > image, and there is more to performance than simply bandwidth. Guacamole > attempts to detect this automatically and use whichever will produce the > best user experience. Forcing WebP across the board will likely perform > noticably poorly. > > >> *Please guide us how i am enable or decode image data/PNG to image >> data/Webp in guacamole server with tomcat with compression?* >> > > Guacamole already does this automatically, and it has nothing to do with > Tomcat. > > Really, I think you are chasing red herrings, trying to solve a problem > that isn't actually in the software. Your recording and bandwidth > measurements both show things working nominally and that the bandwidth > usage is not high. > > I believe the ultimate issue is that you're trying to cram 600 connections > down the same 50 Mbps pipe, and that you are not going to achieve > reasonable performance for those 600 connections simply because that is not > a reasonable resource allocation. Guacamole will still work, but it will be > strongly limited by what you've given it to work with. > > It doesn't hurt to experiment (it's the only way progress happens) and > you're more than welcome to dig through the source on your own and see > whether tweaking things with respect to WebP vs. PNG vs. JPEG helps. If you > do discover an improvement, it would be a very welcome contribution. > > That said, keep in mind: > > * This and many other things have been tried before. Guacamole is as it > currently is because of this extensive testing and design. Using WebP > across the board has been tested, and it performed badly. > * There are bandwidth, encode time, and decode time tradeoffs in using > these various compression schemes. The idea of using WebP across the board > (for browsers that support it) was rejected during initial testing for this > reason - PNG often compresses faster and nearly as well, with the slower > encode time of lossless WebP outweighing any benefit and ultimately making > things slower. > * While there are likely cleverer ways to determine whether PNG, WebP, or > JPEG should be used, and cleverer algorithms to be applied to Guacamole's > cost optimizer, it's unlikely to be as simple as "just use WebP" and > unlikely to produce the order-of-magnitude improvement you would need to > fit all those connections in 50 Mbps. > > - Mike > > -- Thanks & Regards, Manoj Patil.(Asst. Manager DBA) Netwin Systems & Softwares(I) Pvt.Ltd Nasik. Mobile No -+91-9922507588 Email- [email protected]
