>Hello to all,
>
>We have a VFP 5.0 application running on a dedicated NT 4.0 server with a PII 400 Mhz 128 Mb Ram on a 6GB hard Drive. 5 users are accessing the application. Workstations are PII 300Mhz with 64 Mb Ram and 3Gb Hard Drives. On both the workstations and server more than 60% of the HD are free space.
>
>Each workstation may be logged to as many as 3 other servers. The rest of the servers are all Novell.
>
>Additionally the server is supposed have to been moved to a dedicated hub and switch.
>
>The problem is that the application can run at top speed at some times during the day and slow as mud during other times. The primary problem areas are a form that loads a listbox which can have as many as 1000 items with four fields and a research form which also fills a listbox with a result set which may range between 1000 to 3000 items.
>
>Times can range (and looking for the same information I might add) from 3-5 seconds to 45 seconds.
>
>The network staff there is less than helpful and are insisting that the problem must be our app, even though the same app is running like a champ on other client locations with similar equiptment.
>
>I am open to ideas as to what to look for.
>

Ed Pickman is right on the money (as usual) with his statement about the size of your recordsets for listboxes - populating them is likely to be very slow. His recommendation of using a grid, especially if you can use Rushmore-optimized parameterized views to feed them, is likely to give much better performance than a listbox with that sort of recordset size.

You need to prove out that the problem lies in the network rather than in the app's forms or controls. I'd start by trying to run with local data sources and the same size datasets in the listboxes. Try taking the worst-performing system and copying the data to a local drive, and use the same queries to feed the listboxes as you're running over the net. Test this over a long period of time; if issues related to memory bleeds or garbage collection are behind the problem, a couple of quick tests with local data aren't a good indicator. Run that machine with roughly the same transaction volume as the other stations, and if the system performance stays high while the rest of the systems using the network for I/O get starved, you're looking at a network I/O issue, and further investigation of network traffic is probably warranted.

Note that running the data locally is going to boost performance in almost any case where the speed that the data gets to the system is an issue; you're looking for a statistically significant change in performance over time to indicate that local conditions degrade form performance. If the network performance ranges from 3-45 seconds, you're looking for an order of magnitude difference in performance; if your local data seems to run the 3-5 second query in less than a second, but goes up to 5 seconds over time, that's the same order of magnitude difference in system performance, and local system issues are at least in part to blame. If moving the data doesn't make a significant difference in the overall performance of the problem forms, then the problems lie squarely in your app and the local station configuration - you've taken the network load out of the equation.

If you think the problem lies on the server, time to break out PerfMon and do some benchmarking, establish some baseline measurements, and tune things as needed. It's unlikely to be a problem with the CPU load on the server, but it's best to rule it out by proving out that you aren't CPU or disk I/O bound, especially if the NT Server is doing more than just serving up files for your application to beat on across the wire. NT has a number of built-in auditing and analysis tools available as a part of the operating system, and Microsoft has a number of good on-line resources that discuss using them to analyse and tweak NT. There's some helpful information on tuning and server performance on http://www.ntfaq.com as well.

If you're convinced that the server is the issue, and you don't do NT for a living, hire someone who does to handle tuning the server for you. It's probably cheaper to pay a consultant for an hour or two than to learn everything you need to learn about the care and feeding of NT Server if you don't plan to do it for a living, especially since it's going to change again with Win2K in very wide public beta now.

If you think it's network traffic related, hang a sniffer on the net and watch the packet loading on the wire. Even if the server is on a switch, unless the workstations are also on the same switch, the traffic to and from the server is competing with everything else on the most congested segment that the packet has to travel over. You'd be surprised at the things that can bury a network, like a network-attached printer printing up mondo Word documents with lots of graphics, or even casual copying of files between two machines. And if the slowdowns occur at lunchtime, find the gamers playing Doom or whatever across the net and shoot them. With a real gun.