Muliple user and performance

[perl1963]

We are using FoxPro 2.6b and Tom Rettig Office(TRO)
The TRO is a foundation product that we used as a starting point for the system. The system has grow to a point where the performance is critically slow when more then one user is logged into the system. The number of user logged in at any one time varies from 15 to 30. The account base of the product has grown from 30,000 to 125,000 in the last few years. The exe and data are housed on the same server. Users log into the system with a desktop shortcut.

The question, is there any known issues with this setup that would degrade the performance? Or are there way to improve performance in this type of situation?

Perl
Forum-Financial.com

 

[rgbean]

Perl,
It's very difficult to answer this kind of question, there simply isn't enough information. Have you done an network traffic analysis? What's the hardware and software configuration of the network, server(s?) and/or the workstations?

I would normally suggest you contact the developer, but since Tom's been dead for 7+ years, that's not really going to be very helpful. Has the hardware and software been upgraded in this time? Any reason you haven't upgraded the application? (Did you have any Y2K problems?)

Rick

 

[fluteplr]

A few things that may help.

1. If possible move the exe to the users desktop machines. That will cut down a lot of network traffic.

2. Make sure that temporary files (and foxproc uses a lot of these) are being created on the users harddrive not the server harddrive. Look up tmpfiles in configuration settings by default they will go to the same drive as the exe is on so they are probably running on your server which again creates lots of network traffic.

3. Have yo defragged and reindexed the files on the server lately (or at all)? Note in order for the reindex to be effective you need to totally drop the indexes and recreate them. There have been many threads and probably a faq on how to do this.

 

[JRB-Bldr]

Since you say....
"The TRO is a foundation product that we used as a starting point for the system. The system has grown... " I assume that you have the source code.

In addition to all of Rick's excellent suggestions above, have you also done a database analysis?

Is there data that can be archived into different tables so as to expedite usage of the existing table's data?
Or does EVERYTHING have to be immediately accessible to the users?

Are your users using the same version of Windows as before?

Do some users work fine and others less so?

Does performance vary significantly as the number of users increases?

Was Tom Rettig's original code developed so as to handle that large an account base?

Did your new code (code added to the original Tom Rettig Office base product) efficiently utilize the data structures and efficient programming techniques?
Stated another way -- Has your new, added code possibly introduced in-efficiencies?

Does the "slower" performance appear during one type of operation more than another? Example: Tom's part works well, but your new code does not?

What has changed since it was perceived to be working OK and now besides dealing with a larger account base?
* User workstation changes?
* User OS changes?
* Network changes?
* Other changes?

As you can see, there are lots of places to look for problems and in-efficiencies.
Maybe by finding the answers to some of these questions you can begin to eliminate the variables and zero in on the actual problem(s).

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[perl1963]

Thank you all for your comments and suggestions.

We have not upgraded because of some setbacks. A java solution is in the works but we are looking at several months before this becomes available.

The hardware and software have been upgraded. Various networking changes have been made and a great deal of analysis has been performed on the system and the network. The conclusion seems to be that some internal limit has been reached in capacity or number of users and performance is suffering. The current platform is NT 4.0 SP 6

Moving the executable to the local desktop has been avoided as the foundation controls the user login, record locking (adding, updating and deleting records) and other various screen related processes.

On individual users - Inquire slow on 1 machine, but fast on another with the same hardware.

A reverse proportion is seen with regard to the number of users logged on to the system. Less users better results, more users system slows down. A process that takes 15 minutes with a few users can easily take upwards of an hour when several users are logged onto the system.

The changes to the system have been dramatic but for the most part adherence to the foundation have been maintained.

So, yes the whole system has changed - network architecture, OS type, workstations, other software on the workstations, etc...

I was hoping for a document or personal knowledge dump that would clearly point to one thing or another. This is more realistic in hindsight. If this added information rings any bells or point to something. Fell free to respond.

Thanks again for all your advice.



Perl
Forum-Financial.com

 

[EzLogic]

Are you using AntiVirus? Especially Norton?

http://support.microsoft.com/default.aspx?scid=kb;en-us;321550

Ali Koumaiha
TeknoSoft Inc
Farmington Hills, Michigan

 

[JRB-Bldr]

The performance degradation due to antivirus processing is well documented. And it is fairly easy to check out -- merely temporarily disable it and run the program.

I don't know that I agree with your comment: "some internal limit has been reached in capacity or number of users and performance is suffering" There are Foxpro apps out there still running up to 1000 users.

This might be a significant clue:
"On individual users - Inquire slow on 1 machine, but fast on another with the same hardware."
Same hardware, but what else is different?
* Does the network path come through a different number of hubs?
* What other software is running concurrently?
* NIC errors causing multiple data packet re-sends?
* Different CONFIG.FP settings?
* What else?

Have you tried the suggestions by fluteplr yet?

Foxpro applications all run on the individual's PC regardless of where they actually "live". Therefore finding ways to minimize individual user's network traffic will help performance.

Additionally SQL queries and other processes that have to examine LARGE tables will take a good amount of time. Consequently archiving off what you can and reduce the size of tables will also help.

I also assume that you have read postings about appropriate CONFIG.FP memory settings and verified your user's as well?

Is your network still at running at 10 Meg or have you upgraded to 100 Meg yet?

If everything above has been tried, it might be time to look at the code and the data structures very closely. Tom Rettig did things well, but, as I said before, perhaps your changes introduced in-efficiencies or, alternatively, Tom's original program did not anticipate your current account volume and/or user numbers.

Since you apparently have the code, you might want to consider a code review. From that you can determine if changes are mandated.

Just re-creating the same app in a new language might not, by itself, eliminate your problems. Usually the biggest performance improvements are due to using a new approach to the application's requirements, not just doing it in a different language. That same new approach in the same original language (if functionally supported) will often deliver the same improvements.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[perl1963]

Have you tried the suggestions by fluteplr yet?
Yes, we have done what fluteplr said except for relocating the executable. This is a next step, if nothing else produces results.

Is your network still at running at 10 Meg or have you upgraded to 100 Meg yet?
Upgraded to 100, although in at least one case clearing the networking issues (i.e. putting them in a high speed connection) actually caused the application to fail. We had to set one user to the slowest possible network settings to allow his machine to run - it was a higher end desktop.

The code is being reviewed for bottle necks, places where best practices have not been used and any processes that have degraded excessively in performace with the increase in size.

Thanks for all the helpful comments and suggestions hopeful that some may prove fruitful and ideas yet to be seen will shine some light as well.





Perl
Forum-Financial.com

 

[MorgyDogy]

I hope by now this has taken care of itself -but -

I don't know if this was touched, and I hate to sound simplistic but are you connected by hub or switch?

 

[perl1963]

We are connected through a switch, many issue resolved by moving to windows 2000. We are destined to maintain the foxpro 2.6 app for at least the next year to 18 months. So if you have feed back we'll listen.

Thanks in advance

Perl

Perl
Forum-Financial.com

 

[wadesnj]

My Foxpro 2.6a for DOS application with around 30 concurrent users was running on Windows 2000 server with XP workstations and was rather slow. Migrated the application and data to a new Linux server and used Dosemu and putty for the user terminals. There was a vast improvement in speed and reliability, and can now run many more users consurrently without system slowing down. This is a well documented solution for old FPD applications. There is NO local client side install required at all, and can run on very low spec hardware.