Server sizing for Remote Desktop for Visual Foxpro application

I am planning on deploying a relatively small Visual Foxpro application for approximately 133 users. The tables are under 300 Mb.

How can I determine the amount of RAM and CPU capacity to deploy to ensure good performance for the users? I'm looking for personal experience in this field and/or tools available to help me determine the capacity requirements.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
I have a FoxPro 2.6 application running on a 2 GB database used by 70 users extensively. The first server had 2 GB RAM and it was doing quite well.

VFP is not client server when using FoxPro tables as opposed to MS-SQL or MySQL. So you need to concentrate more on network speeds rather than CPU and RAM. The server will be busy dishing out tables and indeces. You also need to ensure that the tables are very well indexed for impeccable performance.
MaritimedAuthor Commented:
Hi CaptainCyril,

As this is a Terminal Server/RDP deployment, wouldn't the network speed be less of a consideration as the files and users are all "local" to the tables? Was your application under this scenario?
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Olaf DoschkeSoftware DeveloperCommented:
Indeed, if you install your tables on the TS the network bandwidth is of no meaning in regard to the data access, as that will be local.

But there is a connection from each user to the TS and that bandwidth is shared. 133 users is much, especially all concurrent.

It's not just about your application and it' RAM usage, it's rather about each users Windows session and CALs.

I am no TS expert, but I think you need lot's more than 2GB Ram to have many concurrent TS sessions. As many concurrent users are much easier served with a web application.

Bye, Olaf.
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
I did not pay attention to the title. :)

Yes my application was on LAN and started with Novell to be exact.
TS consumes a lot of server resources (namely RAM). We refused TS usage for this kind of application and we are rather using Visual FoxPro app as a multithreaded COM server. 100 concurrent users on 16 GB RAM on relatively weak 4 threaded server were OK.  Each COM instance can consume from about 20 MB to 500 MB (when large query is executed). I have to say when many users executed a large query the server was a little bit overloaded... Today's server has no such problems (256 GB, 24 threads) and we still have large capacity reserves.

We don't care about the Visual FoxPro discontinuation because our app can run in virtualized environment under the OS of our choice. Any replacement or rewrite (e.g. to .NET) would cost a lot of money...

Links of your interest for TS planning:
TS Capacity planning
This TS capacity requirement article is very good

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MaritimedAuthor Commented:
Thanks, very helpful.
Olaf DoschkeSoftware DeveloperCommented:
Indeed very helpful links.

To state the obvious, an advantage of TS or RDS is you can serve an application as is, but even the simple RAM estimation done in brian maddens blog shows you, 133 users are quite a huge load. 128MB + 4*133 alone for the sessions. 133 CALs are also not cheap.

There you have enough money to instead invest in making your app a web app. Either as pavel did with COM Servers, or using foxincloud or vfp2iis or afp or west wind tooling. But you have to be prepared to redo you application logic and give it an html front end. Technologies like foxincloud and vfp2iis promise an easy transition, but might work slower than you need.

You can also think about just doing a small part remote users need for web.

And to state something even more obvious: If users are in the LAN, then TS/RDS is the wrong choice anyway. You might also put users in a remote LAN in a WAN. If this is applicable depends on the bandwidth connecting the two or more LANs.

Of course in a few distinct LANs another possible solution is to install a database on each site and do replication, automatic or manual. The less data needs to be common to all LAN live, the less you have to sync, the more syncing may be done off hours.

One (bigger) customer I have uses TS for small sites around the world in China and Mexico, but that's just each having 10-20 users. The rejected the replication idea, because I was told my database does multiple of 10 GB transaction log each day. I somehow doubt that this would cause the same amount of replication transfer data, because not all data changes are needed live, but they won't listen anyway.

Bye, Olaf.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.