1. The WORKS intro says for OI 16/32. Can WORKS subscribers get help with AREV here?

2. We are experiencing random slow downs that bring our AREV airline reservation and aircraft dispatch application to hault.

 a. We recently upgraded the Win2000 Service and NPP to 2.1, but that was no help.  

 b. Our network details are: Arev is running on clustered Windows 2000 servers. There are approxiately 50 users using the app at any one time including several that connect via Cytrix Metaframe. 99% of the users are using Win2000, a couple use WinXP and a couple Win98.

3. Details on the slow downs:

  a. They occur mostly (but not always) in the late afternoon when the most number of users are connected. 

  b. They seem to occur after running a fairly large (taking maybe 30 min to run on a non-indexed field) report. There is not a direct association here. Sometimes the slow down will happen 30-60 minutes after running a report and sometimes speed remains normal. I am not sure I could duplicate a slow down if I had to. 

  c. The slow downs are usually fixed (but not always) by rolling the AREV services over to the other clustered server.

  d. We usually accomplish "c." above immediately, as we are running a reservation and aircraft dispatch system. However, there has been one case where we did nothing and the system resumed normal speed after about 30-45 minutes of being very slow.

  e. We only average about 1 or 2 slow downs a week.

  f. Other (non-AREV) applications do not experience any speed problems.

Does anyone have solutions or some good trouble shooting suggestions?

Thanks,

Ron

1. The WORKS intro says for OI 16/32. Can WORKS subscribers get help with AREV here?

Sure.

2. We are experiencing random slow downs that bring our AREV airline reservation and aircraft dispatch application to hault.

a. We recently upgraded the Win2000 Service and NPP to 2.1, but that was no help.

You probably have fewer GFEs than before.

b. Our network details are: Arev is running on clustered Windows 2000 servers. There are approxiately 50 users using the app at any one time including several that connect via Cytrix Metaframe. 99% of the users are using Win2000, a couple use WinXP and a couple Win98.

The performance will degrade with the advent of Citrix users more than with standard Windows users, especially if reports or part-screen presentation is run.

3. Details on the slow downs:

a. They occur mostly (but not always) in the late afternoon when the most number of users are connected.

Makes sense users=server load=slowdown.

b. They seem to occur after running a fairly large (taking maybe 30 min to run on a non-indexed field) report. There is not a direct association here. Sometimes the slow down will happen 30-60 minutes after running a report and sometimes speed remains normal. I am not sure I could duplicate a slow down if I had to.

Sounds like printer spooling is conflicting with regular network traffic. Check if your Citrix users are trying to print locally. A log file in your application will help you to trap such processing events.

c. The slow downs are usually fixed (but not always) by rolling the AREV services over to the other clustered server.

…which would give the original server more timeslice to complete its printing chores…

d. We usually accomplish "c." above immediately, as we are running a reservation and aircraft dispatch system. However, there has been one case where we did nothing and the system resumed normal speed after about 30-45 minutes of being very slow.

Citrix slowdowns can happen if you simply toggle between full screen and part-screen mode. The extra compute load occurs with re-scaling of the pixel maps of the Windows screen between client and server.

e. We only average about 1 or 2 slow downs a week.

When you get Citrix users printing or else when someone hits Alt-Enter accidentally in a Citrix session using AREV.

f. Other (non-AREV) applications do not experience any speed problems.

Does anyone have solutions or some good trouble shooting suggestions?

OK -

Are you using AREVFIX.COM? This is a Citrix utility good for AREV.

Are you using CPUPLUS? This is an AREV utility good for Citrix

Are any Citrix users running reports to local printers?

Have you checked all the AREV Windows shortcuts to ensure that they are tuned to enable background processing and 60-80% idle sensitivity?

Have you set the screen resolution to 640*480 where possible (which effectively gives Citrix less screen data to transmit?

Have you checked the network to see which processes are the culprits? Is it always AREV (NTVDM)?

Have you got backups or scheduled processes which run at set times?

Is your Virus Checking software set to disable scans of *.ov files?

Is the power-save feature disabled on all workstations?

Is AREV's indexing feature disabled on the Citrix workstations? (You don't want to be rebuilding indexes from a Citrix terminal when someone leaves their keyboard at lunchtime).

Are your Citrix users logging off or merely disconnecting after their sessions? Idle Citrix sessions can rob CPU dramatically.

How big is your disk swap file? This could get untidy later in the day. Sometimes, enforcing a smaller swap file (or even *less* server RAM) actually *improves* throughput, because you don't get swap-file thrashing.

Who has viruses or Spyware loaded? (go to www.symantec.com or www.ad-aware.com to solve this).

There are a few options here, but basically, with 50+ users per server and Citrix in the mix, we'd be asking all these questions, and logging application actvity and server activity to identify the culprit processors/workstations. We'd also be checking your version of AREV - if it's 3.12 then enable Yield time to Windows in SYSPROG. Otherwise you will probably need to look at the other options above.

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks, Steve

We are looking at all your suggestions. I don't think it is Citrix related…only a few users and they do not print locally or ever use full screen.

We have excluded *.ov from the virus scans and hope that improves the situation.

Ron

Steve,

Thanks for responding.

Yes, Scenic is using both ArevFix.com and your CPU+ utility

Citrix users will typically only print a one page flight manifest rather than an in-depth ad-hoc report.

Scenic knows to uncheck the "suspend background operation" checkbox, but there is the possibility that some workstation still is locking up the SYSOBJ table and only allowing the background "trickle" of access.

I believe that their Citrix client is running at 800x600, but I will double-check this.

Have you checked the network to see which processes are the culprits? Is it always AREV (NTVDM)?

I don't know, but it is clearly AREV that slows down.

Have you got backups or scheduled processes which run at set times?

Ron - you will have to double check this…

Is your Virus Checking software set to disable scans of *.ov files?

Ron - you will have to double check this…

Is the power-save feature disabled on all workstations?

Is AREV's indexing feature disabled on the Citrix workstations? (You don't want to be rebuilding indexes from a Citrix terminal when someone leaves their keyboard at lunchtime).

Indexing is disabled at all workstations and is handled by a dedicated processor in the server room.

Are your Citrix users logging off or merely disconnecting after their sessions? Idle Citrix sessions can rob CPU dramatically.

I don't know about Scenic's users, but I am personally guilty of just disconnecting….

How big is your disk swap file? This could get untidy later in the day. Sometimes, enforcing a smaller swap file (or even *less* server RAM) actually *improves* throughput, because you don't get swap-file thrashing.

Who has viruses or Spyware loaded? (go to www.symantec.com or www.ad-aware.com to solve this).

Ron - you will have to double check this with Chris….

Yeah, it is really odd. None of the other airline clients have this problem, but late afternoon the system dogs down to unacceptable levels. It sometimes seems to be related to running some ad-hoc report or process that extracts data from the primary reservation data table (approximately 800,000 records).

I suggest you investigate the SIZELOCK parameter of your linear hash files. If any are set to 2 or larger then you can get inefficient processing of the tables. Especially, LISTS and SYSTEMP.

Make sure SYSTEMP is flushed (CLEARTABLE) when no one is using the system. There could be a lot of temporary rows in that table that were'nt properly discarded.

For the LISTS table I'd use DUMPLH and check the number of unused overflow frames with a Ctrl-D. If more than a pageful consider copying all rows to a temporary table, then CLEARTABLE LISTS when no one is using the system and copy those rows back to LISTS.

Dave

FYI,

As mentioned in another response, we are running a dedicated index server. We found last week that stopping and restarting the indexer fixes the slow downs. This explains why moving to a new cluster fixed the problem…it forced a restart of the indexer.

Now, I don't know why the indexer would be causing the slowdown. However, it is a very easy, quick fix and doesn't knock everyone out of the app.

Thanks to everyone for their advice and suggestions.

Chris

View this thread on the Works forum...