Hope this helps, this is how we get past the limitation of concurrent
connection users (CCU)
*1. CPU*
* *Minimum*: 8 vCPUs
* *Optimal*: 16-32 vCPUs depending on the intensity of user sessions
and the types of remote connections (e.g., RDP, VNC, SSH).
o Guacamole's backend services (Tomcat) and the guacd daemon
benefit from higher CPU cores for concurrent session management.
*2. RAM*
* *Minimum*: 16 GB
* *Optimal*: 32-64 GB
o Allocate memory based on the average session count and types of
connections (e.g., RDP requires more RAM per session compared to
SSH).
*3. Storage*
* *Disk Space*: Depends on log retention, drive sharing, and session
recording needs.
o *Base Installation*: ~10 GB
o Allocate additional space for:
+ Logs: 100 GB+ if extensive logging is enabled.
+ File sharing: Depends on user needs.
* Use SSDs for better performance.
*4. Network*
* *Bandwidth*: At least 1 Gbps is required for smooth operation; 10
Gbps is ideal for high-volume environments.
o Each session consumes about *50–150 kbps*, depending on the
resolution and activity level.
* Configure network settings for optimal performance:
o Ensure low latency for remote connections.
o Use load balancing if needed.
*5. Guacamole Configuration*
* *guacd Instances*: Each guacd instance can handle ~100–200
simultaneous sessions.
o Deploy multiple guacd instances using Docker or separate servers
for scaling.
o Use a load balancer (e.g., NGINX, HAProxy) to distribute traffic
among guacd instances.
*6. Tomcat (Guacamole Web Application) Tuning*
* *Heap Size*: Set the Java heap size for Tomcat:
-Xms8g -Xmx16g
This provides 8–16 GB of memory for the web application.
* *Thread Configuration*: Increase the number of threads in the Tomcat
connector configuration in server.xml:
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="500"
minSpareThreads="100"
connectionTimeout="20000"
URIEncoding="UTF-8"/>
*7. Database*
* Guacamole stores user information and connection details in a
database (e.g., MySQL, PostgreSQL).
o Ensure proper indexing for large user bases.
o Use *read replicas* for load distribution if querying becomes heavy.
*8. Scalability*
* Use a *clustered architecture*:
o Multiple application servers for the Guacamole frontend.
o Multiple guacd servers distributed via a load balancer.
o Centralized database with high availability.
*9. Monitoring*
Implement monitoring tools to ensure resource utilization and
performance stability:
* *CPU and RAM*: Monitor usage and scale horizontally/vertically as
needed.
* *Session Metrics*: Monitor active session counts and peak usage times.
* *Logs*: Centralized logging (e.g., ELK stack) for analyzing errors
and trends.
*Example Deployment for 10,000 Users:*
* *Frontend Servers*: 4 (each with 8 vCPUs, 16–32 GB RAM).
* *guacd Servers*: 5–10 instances (each with 8 vCPUs, 16 GB RAM).
* *Database*: 1 primary + 1 replica (8 vCPUs, 32 GB RAM).
*Thank You*
Sean Hulbert
On 7/28/2025 3:22 AM, Tobias Feller | OPC wrote:
Hi Nick, Hi Alex,
@Nick
/"I've got a very similar environnent (guacd 1.5.5 on CentOS 7), and
it's been running for several weeks with hundreds of connections
having been made with it and I've not seen this issue."/
The Problem was for me only on *concurrent connections*. I'm running
also the 1.5.5 (docker) on our two guacamole (Loadbalanced) Hosts
since some month without problems. but with this 2 hosts we don't hit
the 60 concurrent connection limit at the moment.
Maybe i can try to do a test on another standby host that is using 1.6
and connect via some servers to 60 hosts at the same time.
Tobias
Am 28.07.2025 um 12:07 schrieb Alex_Yin:
I am running guacd 1.5.5 on Centos 7.9 vm
---- Replied Message ----
From Nick Couchman<[email protected]> <mailto:[email protected]>
Date 07/28/2025 17:54
To user<[email protected]> <mailto:[email protected]>
Subject Re: [EXT] SSH Connection Limit of 60 per guacd
On Mon, Jul 28, 2025 at 04:21 Alex_Yin <[email protected]> wrote:
Hello Julian,
Thank you for your suggestion. My problem is indeed very similar
to the link you provided. I also found this bug link
https://issues.apache.org/jira/browse/GUACAMOLE-1998. It seems
that it has not been solved yet. I found two solutions from these
two links:
1. Use version 1.5.3;
2. Build guacd image based on Debian 12.
I think I can try to roll back to version 1.5.3 first.
What version of guacd are you running when you encounter this?
Part of the challenge with the issue linked above is that we've been
unable to reproduce the issue reliably - I've got a very similar
environnent (guacd 1.5.5 on CentOS 7), and it's been running for
several weeks with hundreds of connections having been made with it
and I've not seen this issue. There must be some other factor
contributing to producing this behavior, we just haven't figured that
out, yet.
-Nick
