Client Server

[omni]

Roger,

I know you (and others) are big supporters for the client server. Our users have never had any real issues and have never wanted to pay extra dollars for something that is not required. Hard enough to get them to pay for our software.
We have one client that has 50-75 users and all are connected using remote access to one terminal server. There has been discussion years ago that the client server, as far as how the files are handled (ie, no work stations) are not as necessary in that type of environment.
Recently they have had a lot of file read, or just the app closes without warning or just stays locked up trying to open a menu. No error logs. Would probably guess that the files are failing opening or timing out. They reboot and then are ok. Seems now to happen daily in the afternoons.
Any thoughts? Any known limitations on the number of users on a single terminal server that will function effectively in our environment?
Maybe he needs more memory.

Fred
Omni

[rdonnay]

That seems like a lot of users on one terminal server. You could be running low on memory.

[Tom]

Check the logs. You may get a conflict concerning the maximum number of available TCP-connections. Memory consumption might be a problem. Are you switching processor kernels in you app? If not, try to do so. It's quite easy to access the number of processors and/or kernels. Select a random number and run the instances of your app on different processors. Look at the samples in ..\Source\Samples\Solution\smp of your Xbase++ installation. You may even switch the kernel while the app is running.

Besides, an app using a standard DBE requests a handle for each table and index opened. If 50 instances of your app run and everyone of them opens 100 tables, you have at least 5,000 file handles in use, causing low level operations on the system. Using a database server like the ADS, this number goes down, since the server opens every table in use only once (and caches data). This avoids file conflicts and corruptions, and it reduces traffic.

[rdonnay]

Are you switching processor kernels in you app?

Call DC_SetCpu() at the beginning of your program. This will switch processors each time the app is run.

Also, make sure that you have not compressed any of your DLLs.

[Tom]

Call DC_SetCpu() at the beginning of your program.

DC_SetCpu() writes the processor used to a file (default: <Windows>\Temp\SetCpu.Smp) and selects the next one until the number of processors is exceeded, then it restarts at "1" (one). This is one of the possible strategies to select processors. The others are:

a) Track all users currently logged in to your application and select the processor with the lowest number of users on it.
b) Try to find the processor with the lowest utilization. There are registry keys which return the processor utilization.
c) Select the processor by a random number from 1 to the number of available processors.

We tried out all approaches including Roger's. a) Is not really good since users may kill the app, but remain tracked. Besides, users A and B on processor 1 may do nothing, while user C on processor 2 creates heavy traffic. Processor 2 maybe a bad choice in that situation. b) Does not work very well, since it gives a snapshot, and the utilization may and will change in the next second.

We came to the conclusion that c) is the best. In addition, a user may switch the processor while the app is running. A table shows which user is on which processor.

Anyway, switching processors is essential in a Terminal Server environment. Most of the servers come with at least 4, normally with 8 or 16 kernels. Xbase++ applications run on processor one by default. If 50 users do this, 15 processors don't do anything, while one has all the work.

[omni]

Yes,, we do use that processor assignment. They have 4 processors. My first inclination was that they keep adding locations and users, and its just a memory issue. Checking their processor usage, all 4 cpu's are about the same.. The external users pretty much all do the same few menu options. Local users do the heavy stuff, like accounting,etc.

Fred
Omni