5.8 GUI Slowness via VPN…

Thomas:

We aren’t on 5.8 yet but could end up on 5.8 if we upgrade anytime soon so I find this post of interest.

I noticed a big improvement in Cloverleaf 5.6 GUI response over 5.2 when going through our VPN and using remote desktop to control a work PC that had the GUI client loaded on it.

I’m curious which one of these 2 possible remote access methods are you using:

    1) running the GUI client installed locally on a PC outside the VPN.

    2) using a PC outside the VPN to gain corporate access and using something like remote desktop to control a work PC inside the corporate firewall and then launching the Cloverleaf GUI on the PC inside the corporate firewall.

I prefer method 2 above but did observer method 2 was painfully slow in Cloverleaf 5.2 but method 1 in Cloverleaf 5.2 wasn’t nearly as slow.

I hope I’m not going to be pained into resorting to method 1 again when we go to 5.8, it has been really nice how responsive VPN/RDP has been since upgrading from Cloverleaf 5.2 to 5.6.

Russ Ross wrote:

2) using a PC outside the VPN to gain corporate access and using something like remote desktop to control a work PC inside the corporate firewall and then launching the Cloverleaf GUI on the PC inside the corporate firewall.

That is my preference as well.

This post just jogged my memory about a slowness problem I had on a new refreshed PC that might be worth a try if it applies to your case.

Later versions of Adboe have some controversial spyware bundled in it that significantly impacted the performace of my PC.

I became aware of it when one of my firewalls (Online Armor) caught it.

Then after googling AdobeARM, I decided to run -> msconfig and unchecked AdobeARM from the list of things in the startup tab and saw major if not astonishing improvements in my VPN/RDP access.

This problem isn’t specific to Cloverleaf and slows down the entire system and everything I did via VPN/RDP even things like reading email was painfully slow with AdobeARM running.

Thomas, I would suggest placing a ticket with tech support.

Great. Let us know what you learn. 🙂

Thomas:

I was wondering even though Method #1 is slow to launch does the GUI perform okay after the inital 90 second snooze?

If you have someone there familiar with network troubleshooting, you could try running a sniffer (like Wireshark) on the PC that is running the client to see what kind of network activity is happening right before the delay.

I know that with an older version of Clovlerleaf we saw an issue where the client was sending a ping (ICMP request) and wasn’t completing the connection until the ping was answered or timed out. Because ICMP was being blocked on VPN connections, we were seeing the same type of delay.

Have you noticed a general increase in the GUI load time regardless of whether you’re working local or remote?  How many sites do you have?

When we upgraded from 5.5 to 5.7, the GUI slowed down tremendously (from seconds to a couple of minutes).  This was due to the fact that the Cloverleaf license is checked for each site in the server.ini file.  I have since created my own launch script that effectively bypasses the checks.  I think checking the same license key for each site is a little excessive.

Steve

We noticed this slowness in 5.7 as opposed to 5.5, even with the client and server on the same LAN. In 5.5 the NetMonitor would start in max 10 seconds; in 5.7 it would sometimes take up to 2 minutes and all the while the processor of the client would run on 100%. So first thing we did was change clients (we had very old ones), but still very slow after that (about 40-50 seconds).

Then we disabled the ‘Use textured background’ and enabled the ‘Enclose thread name in thread graphics’ in the Client Options, tab Netconfig/Netmonitor. Now it takes about 20 seconds for the Netmonitor to start. Still slow, but acceptable. Well… We are not yet in production with 5.7 so the annoyance will start later I guess.

We only have one site, but with 15 processes and about 110 threads.

Tom,

It’s pretty basic.  I use a batch file to launch a tcl script that edits the client.ini file.  The slowness that I see is related more to changing sites than actually launching the GUI.  Since the GUI launches into the last server/last site by default, I simply change that information in the client.ini before it launches.  With a minor tweak, I can also launch the GUI into a valid site that isn’t listed in the server.ini file.  Below is the code:

#! C:/Tcl/bin/tclsh85

package require ftp

set FH [open C:/quovadx/qdx5.7/integrator/client/client.ini r]

set data [read $FH]

close $FH

set data [split $data n]

set index [lsearch $data “hosts=*”]

set hostList [lindex $data $index]

set hostList [lindex [split $hostList =] 1]

set hostList [split $hostList ,]

set hostItem “”

while { $hostItem == “” } {

 puts “ttSelect Host Servern”

 set cnt 0

 foreach host $hostList {

   incr cnt

   set hostArray($cnt) $host

   puts “tt$cnt)  $hostn”

 }

 puts -nonewline “tChoose host number or type in hostname:  “

 flush stdout

 gets stdin hostItem

 if { ($hostItem == “”) || ($hostItem > $cnt) } {

  set hostItem “”

   continue

 }

 if { [string length $hostItem] == “1” } {

   set host $hostArray($hostItem)

 } else {

   set host $hostItem

 }

}

set user “loginID”

set passwd “loginPassword”

set remoteDir “/quovadx/qdx5.7/integrator/server”

set FTP [ftp::Open $host $user $passwd]

ftp::Cd $FTP $remoteDir

ftp::Get $FTP server.ini -variable serverData

ftp::Close $FTP

set serverData [split $serverData n]

set index [lsearch $serverData “environs=*”]

set line [lindex $serverData $index]

set siteList [lindex [split $line =] 1]

set siteList [split $siteList “;”]

set siteList [lsort $siteList]

set masterSiteList “”

foreach site $siteList {

if { $site == “” } {

continue

}

set site [file tail $site]

lappend masterSiteList $site

}

set siteItem “”

while { $siteItem == “” } {

puts “ttSelect Siten”

set cnt 0

foreach site $masterSiteList {

incr cnt

set siteArray($cnt) $site

puts “tt$cnt)  $siten”

}

puts -nonewline “tChoose site number or type in site name:  “

flush stdout

gets stdin siteItem

if { [lsearch -exact $masterSiteList $siteItem] != “-1” } {

set site $siteItem

break

}

if { ![string is digit $siteItem] } {

puts “string is not a digit”

set siteItem “”

continue

}

if { ($siteItem == “”) || ($siteItem > $cnt) } {

set siteItem “”

continue

} else {

set site $siteArray($siteItem)

}

}

set index [lsearch $data “last_host=*”]

set newLine “last_host=$host”

set data [lreplace $data $index $index $newLine]

set index [lsearch $data “last_environ=*”]

set newLine “last_environ=/quovadx/qdx5.7/integrator/$site”

set data [lreplace $data $index $index $newLine]

set data [join $data n]

set FH [open C:/quovadx/qdx5.7/integrator/client/client.ini w]

puts $FH $data

close $FH

exec c:/quovadx/qdx5.7/integrator/clgui/bin/hciaccess.exe &

exit

We also had this problem in 5.8 in every situation with a firewall / VPN involved.

I found out the Cloverleaf 5.8 Host Server tries to connect to a port on the Client when opening a Network Monitor or Network Configurator. Our problem was that the firewall blocked the traffic from the Host Server to the port opened on the Client. In the example below the problem was caused by port 2513.

Host Server

Code:

-bash-3.2$ netstat -an | grep 10.13.113.180
tcp   0   52 ::ffff:10.125.0.2:32     ::ffff:10.13.113.180:2494   ESTABLISHED
tcp   0   0 ::ffff:10.125.0.2:13019   ::ffff:10.13.113.180:2510   ESTABLISHED
tcp   0   0 ::ffff:10.125.0.2:14019   ::ffff:10.13.113.180:2511   ESTABLISHED
tcp   0   0 ::ffff:10.125.0.2:14019   ::ffff:10.13.113.180:2512   ESTABLISHED
tcp   0   1 ::ffff:10.125.0.2:41537   ::ffff:10.13.113.180:2513   SYN_SENT

Client

Code:

C:Documents and Settingsleont>netstat -an | grep 10.125.0.2
TCP    10.13.113.180:2494     10.125.0.2:32          ESTABLISHED
TCP    10.13.113.180:2510     10.125.0.2:13019       ESTABLISHED
TCP    10.13.113.180:2511     10.125.0.2:14019       ESTABLISHED
TCP    10.13.113.180:2512     10.125.0.2:14019       ESTABLISHED

C:Documents and Settingsleont>netstat -an | grep 2513
TCP    0.0.0.0:2513         0.0.0.0:0           LISTENING

Hello

We have the same problem betwen a CLV5.8 Linux server (on VMWare) and our clients (CLV5.8 Client- Windows XP).

The client takes 2 seconds to connect to the site, but when we launch the network Monitor(or other module), it takes about 5 min.

If I open, close and reopen the network Monitor(or other module), it takes another 5 minutes…

If the network Monitor is already open by another client, when i open it, the lock manager window appears immediatly (module is locked by another user, open read only yes / no…), and after answer (yes or no), it takes 5 minutes to open the module again.

Note, when I connect to a Windows server (CLV 5.8) with the same client, I don’t have the problem.

On my linux server, the firewall is disabled.

We are having the same problems as well. 5.8 running on windows server 2008.

I’m having the same issue with 5.8.  It is all the time – not just when accessing via the VPN. The NetMonitor and NetConfig take approximately 1 1/2 minutes to load.  I don’t have the issue in 5.6.

If it is all the time and not just with the VPN then I would check the routing tables on the server.  Based on what I have seen using netstat and playing around with it, it looks like the hostserver queries the client for its real IP address and attempts to communicate back to the client via that IP.  If the client IP is being nat’ed then chances are very good that there is not a true route directly back to the client machine (via its true IP address).  Apparently it does not rely on this connection in order to work, but it won’t fall back to sending IP until it times out trying to reach the clients real IP.  Theoretically that is why there is the significant delay.

I have not yet found a way around this but I know that accessing a box that is local to me, instead of going to a box at our hosting service, I get the immediate returns that I expect (and that I get either way when using 5.6).

Has there been a resolution to this issue? I tried to use the 5.8 GUI over a VPN yesterday and had the same problem: NetConfig and Network Monitor take several minutes to load.

Thanks,

Rob

I recently started having a loading delay like that, coincident with a network change.    That may have been unrelated.

Bouncing the monitor daemon using hcisitectl is what worked for me.

I’ve been experiencing extreme lag with the Cloverleaf client as well and this is when I’m on the same network as the Cloverleaf server itself.