Significant performance issues between Guacamole & Native RDP

Help
Jason Weir
2014-01-29
2014-03-21
  • Jason Weir

    Jason Weir - 2014-01-29

    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.

    Any ideas?

    Thanks,
    Jason

     
  • Michael Jumper

    Michael Jumper - 2014-01-29

    Do you have any numbers on actual CPU and network load on the host and the Debian guest?

    What virtualization software is in use?

     
  • Jason Weir

    Jason Weir - 2014-01-30

    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

    Any ideas?
    -J

     
  • Jason Weir

    Jason Weir - 2014-01-30

    I went back and edited the user mapping xml file and added the following lines

    <param name="color-depth">8</param>
    <param name="disable-audio">true</param>
    

    This cut the network bandwidth down to right around 50Kbps but still 5X higher than the MS client

    Jason

     
    Last edit: Jason Weir 2014-01-31
  • Michael Jumper

    Michael Jumper - 2014-01-30

    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 mike.jumper@guac-dev.org), 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.

     
  • Jason Weir

    Jason Weir - 2014-01-31

    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.

    Jason

     
  • Jason Weir

    Jason Weir - 2014-01-31

    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

    # ifconfig
    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
              collisions:0 txqueuelen:1000
              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
    ^C
    0 packets captured
    0 packets received by filter
    0 packets dropped by kernel
    
     
  • Michael Jumper

    Michael Jumper - 2014-02-09

    There should definitely be traffic. Are you sure eth0 is the right interface?

     
    • Jason Weir

      Jason Weir - 2014-02-10

      Mike,

      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..

      Thanks,
      Jason

       
  • Jason Weir

    Jason Weir - 2014-03-04

    Any update on this? Still experiencing the performance issues.

    Thanks,
    Jason

     
  • Michael Jumper

    Michael Jumper - 2014-03-05

    Hi Jason,

    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.

     
    • Jason Weir

      Jason Weir - 2014-03-21

      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.

      Thanks,
      Jason

       
  • Winston

    Winston - 2014-03-06

    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

    web browser constraint is difficult to solve. Because Javascript is dynamic lanuage in client side, although node.js compiles javascript as static language at server side.

    It is technically unfair for performance comparison between native RDP and RDP gateway.

    Best regards,

    Winston Hong

     
  • Michael Jumper

    Michael Jumper - 2014-03-06

    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.

     
    • Jason Weir

      Jason Weir - 2014-03-21

      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?

      Jason

       
      • Michael Jumper

        Michael Jumper - 2014-03-21

        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?

         
        • Jason Weir

          Jason Weir - 2014-03-21

          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..

          -J

           

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks