I have Guacamole 0.8.3 running on a virtual Debian 7.1 guest. The virtual host is also running a number of windows 2008 servers and windows 7 workstations.
We have a process we run from a workstation that uses an mssql backed application (sql server is on the windows servers).
If we connect to the workstation with native rdp (mstsc) and run the process it takes 40 minutes, if we instead use guacamole to connect to the workstation the run time increases to over 2 hours.
There is little to no change in display during the process - basically just a progress bar.
Guacamole seems to be rock solid and working without errors it just seems to be adding additional load on the workstation causing the process to take longer.
Do you have any numbers on actual CPU and network load on the host and the Debian guest?
What virtualization software is in use?
CPU\Memory load shows no noticeable difference between a guacamole connection or microsoft rdp client.
Network throughput show a 10X difference, with a guacamole connection is stays steady above 100Kbps, where mstsc stays below 10Kbps.
We have the ms client configured for 16bit and a low speed connection, I don't see these as configurable options on guacamole.
This is all running on a VMWare ESXi 5.1 host
I went back and edited the user mapping xml file and added the following lines
This cut the network bandwidth down to right around 50Kbps but still 5X higher than the MS client
Would you be willing to send us a copy of a tcpdump from the machine hosting guacd?
tcpdump -B 4096 -w guacd.pcap -i eth0 -p "tcp port 4822"
The interface "eth0" may be different, especially since you're running on virtualized hardware.
If you send the resulting pcap file (email to email@example.com), I can run it through a debugging tool and see exactly what's happening on your end. Otherwise, it's hard to guess.
If you decide to do this, beware that the pcap file will contain the same parameters that are given to the Guacamole connection, which may include the username and password, as well as mouse movement and key strokes.
I can probably get you a pcap. Some more info for your troubleshooting. If we run the application minimized network throughput drops and the process takes about 40 minutes to complete. Running the application maximized times jump to over 5 hours for the same process. There is very little screen changes just a progress bar.
hmmm - not seeing any port 4822 traffic
#netstat -a | egrep 'Proto|LISTEN'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:4822 *:* LISTEN
eth0 is the only interface
eth0 Link encap:Ethernet HWaddr 00:0c:29:99:99:99
inet addr:172.26.x.x Bcast:172.26.x.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2509587 errors:0 dropped:0 overruns:0 frame:0
TX packets:3730233 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:945056873 (901.2 MiB) TX bytes:2119924083 (1.9 GiB)
tcpdump gives no output on this - and I have an guacamole rdp connection open
# tcpdump port 4822
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
There should definitely be traffic. Are you sure eth0 is the right interface?
eth0 is the only interface on the box - but since it's a vm strange things can happen - I changed to -i any and now am seeing the port 4822 traffic (to and from localhost).
I've emailed you the pcap..
Any update on this? Still experiencing the performance issues.
I went over the pcap you sent using our internal debugging tool to replay the session, and didn't see anything out of the ordinary. I'll take another look later, but at the face of it, I don't see why this would cause performance problems on other theoretically-independent machines.
On a slightly different note, I thought you said the problems were apparent when the only thing changing is a progress bar? The pcap showed a general demonstration of opening and closing typical Windows and MS Office applications.
Mike - sorry for the delay, was working on other things..
Let me see if I can explain this in a different way..
With our application running maximized, the only (visible) screen changes are a progress bar the process took 2 hours to run.
If I minimized the application the process took only 40 minutes.
I see much higher bandwidth usage with the app maximized versus minimized and that was what I was trying to demonstrator in the pcap.
I see the same higher bandwidth usage when opening and closing regular windows and office applications than I do with native rdp, again that was what I was trying to show.
Hello Jason Weir.
Quote your comment "If we connect to the workstation with native rdp (mstsc) and run the process it takes 40 minutes, if we instead use guacamole to connect to the workstation the run time increases to over 2 hours."
40 minutes vs 2 hours is reasonable.
Let us look at the difference between RDP gateway and native RDP.
Working mechanism of RDP gateway: data from local Windows 7-->web browser-->RDP gateway-->remote Windows 7
3 contraints: (1) web browser constraint
(2) bandwidth contraint of web browser-->RDP gateway
(3) bandwidth contraint of RDP gateway-->remote Windows 7
Working mechanism of native RDP: data from local Windows 7-->remote Windows 7
only one contraint: bandwidth contraint of local Windows 7-->remote Windows 7
Solution for contraints of RDP gateway:
Let RDP gateway locates at the same local network as remote Windows 7 (192.168..),
then we have only one bandwidth contraint: bandwidth contraint of web browser-->remote Windows 7
It is technically unfair for performance comparison between native RDP and RDP gateway.
I wouldn't call 3x as long reasonable.
The problem here is not native vs. HTML5 (where the difference is supposed to be negligible), but rather how is the gateway having a negative impact on unrelated processes.
Thanks again Mike & Winston
FYI all three boxes (Win7 Browser, Guacamole Gateway, and Win7 RDP Server) are on the same physical network and 2 of them the Gateway and RDP Server are on the same virtual host, all gigabit connections, should be no bandwidth issues.
Some of what Winston says confuses me - how does the gateway put a greater load on the rdp server than a native rdp client would?
It doesn't. If there is higher load, it is not because of the gateway nature. I think he is talking about native clients vs. browser-based clients, which isn't the issue here.
Could you send a pcap simply of the progress bar that you described?
I don't think so - I may have a disclosure issue.
Let me play around and see if I can replicate it in another fashion..
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.