Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1235
  • Last Modified:

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.
0
Maritimed
Asked:
Maritimed
  • 2
  • 2
  • 2
  • +2
1 Solution
 
CaptainCyrilCommented:
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.
0
 
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?
0
Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

 
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.
0
 
CaptainCyrilCommented:
I did not pay attention to the title. :)

Yes my application was on LAN and started with Novell to be exact.
0
 
pcelbaCommented:
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
0
 
MaritimedAuthor Commented:
Thanks, very helpful.
0
 
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.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now