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
