Re:Re: Re: Re: concurrent performance of Guacamole

[崔** <ch...@163.com>]

Today, we did concurrent testing again.
There's a lot of similar information in tomcat log file.
You can view the attachments.


-cuihx







在 2020-01-16 15:30:59，"Tushar Jain" <tu...@hitachi.mgrmnet.com> 写道：

Also, having a look at Syslog and servlet container logs(e.g. Tomcat) will be a good idea to start troubleshooting. Do share the  details, if you see any errors in these logs










On Thu, Jan 16, 2020 at 12:53 PM Tushar Jain <tu...@hitachi.mgrmnet.com> wrote:

Hi Cuihx,
> What resources do you currently have allocated?

I don't understand what resources you mean.
This means RAM, CPU, HDD, Network Bandwidth (between Guacamole server and OpenStack server/VM). Can you use some kind of performance monitor to see what is the utilization of each during concurrency peak? Please let us know for both.


> What kind of usage is expected in general within your users' remote desktop sessions?
We don't care this, the problem is “multiple reconnections during the initial access”.
What this means is that you do not have any concurrent performance problem once the user is connected. Your problem is just initial reconnections. Is that a right assumption?


What i have observed in my implementation of Guacamole is that initial reconnections are primarily due to one of the following:


1. Remote VMs refusing the connection to Guacamole, instead of it being a problem with Guacamole itself. This could be due to connectivity problem between Guacamole server and your openstack VM. This could also be due to max resource utilization on your openstack VM
2. Number of concurrent connections exceeding the "maximum number of connections" property under connections
3. Previous connection of the same user with same VM is not completely disconnected.
You may want to check one of these as well.








On Thu, Jan 16, 2020 at 12:00 PM 崔** <ch...@163.com> wrote:

About 20% of the users had multiple reconnections during the initial access, but they were able to connect successfully in the end.
Everything is OK after connecting successfully.
Network is OK, this is a concurrent test within the same network.


> What resources do you currently have allocated?
I don't understand what resources you mean.


> What kind of usage is expected in general within your users' remote desktop sessions?
We don't care this, the problem is “multiple reconnections during the initial access”.















在 2020-01-15 15:45:45，"Mike Jumper" <mj...@apache.org> 写道：

On Tue, Jan 14, 2020, 22:27 崔恒香 <ch...@163.com> wrote:

My application connects VMs in openstack through guacamole.


The concurrent number is about three hundred.


Some users saw multiple reconnections and were finally able to connect.


We want to reduce the incidence of reconnection.


This is still fairly vague. Are you referring to users being unable to connect, being unexpectedly disconnected, or both?


How many do you mean by "some"? What is the general experience for users that are able to establish a connection? Have you been able to confirm that network disruption on the user side is not a factor?


Also, from the previous email:


> What resources do you currently have allocated?


> What kind of usage is expected in general within your users' remote desktop sessions?


- Mike






 



Disclaimer: This message and any attachment may contain confidential, proprietary information and is intended only for the individual named. If you are not the original intended recipient and have erroneously received this message, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Hitachi MGRM Net E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Hitachi MGRM Net therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. Hitachi MGRM Net Ltd, C - 6/5, Safdarjung Development Area, New Delhi - 110016, India


'Please consider the environment before printing this e-mail'.