- This topic has 21 replies, 14 voices, and was last updated 10 years, 11 months ago by
.
-
Topic
-
We are scheduled to upgrade to 5.8 next month. We are in the midst of our testing but are having issues with GUI slowness. When trying to work remotely via VPN, the GUI (i.e NetConfig, NetMonitor, etc) will take a good 2-4 minutes to load. We currently are on 5.6 and don’t experience the slowness when working remotely. Has anyone else who is on 5.8 seen this behavior? If so, what did you do to correct the issue?
Thanks…
Tom Rioux
-
Replies
-
-
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
RussRoss318@gmail.com -
-
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.
Russ Ross
RussRoss318@gmail.com -
Max/Russ,
We currently use method #1. I have a laptop that has the client installed on it and access is through the VPN. I have observed the following using method #1:
With 5.6, I can start a NetConfig/NetMonitor GUI and have it pop up in a matter of 6-8 seconds.
With 5.8, I can start a NetConfig/NetMonitor GUI and it will take 90 seconds or more to show up.
You would think that with 5.8 things would work similar to 5.6. We have found no one that can explain how or why this slowness is occurring. The only solution they have come up with to use the #2 method.
Everyone here likes the way 5.6 is working with method #1 and hope that someone in support will find a solution to allow us to continue to do this with 5.8.
Thanks…
Tom Rioux
-
-
-
-
-
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
-
Steve,
We are noticing the slowness mostly when working remotely through the VPN. A couple of our Cloverleaf users have experienced slowness here in the office or from working at one of our facilities.
We have 22 production sites. I was wondering if the checks you are speaking of happen in 5.6 as well or is it something new with 5.7 and above? Also, if you are able, I’d love to see a copy of your launch script.
Thanks….
Tom
-
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.
Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
-
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_SENTClient
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 ESTABLISHEDC: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.
-
-
-
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).
-
-
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
