>First of all, is this a VFP database? If so, I assume you're simply proposing to move the VFP data files to one machine, and have two others run your Web application.

Yes, VFP.

>- the two separate app servers will no longer be able to open files EXCLUSIVEly

Yes, no problem.

>- bandwidth to data files will be slower - 100Mbit Ethernet is much slower than a local disk or, better yet, local RAM cache. Some of this will be offset by VFP local data caching

Yes, this was my major concern. So, does this mean when comes time to load balancing that I would have to go to client/server? That's why I started this thread. I wanted to know how far we could go with VFP with supporting major loads.

>- if your current Web app is CPU-bound, having another server increases available CPU resources. OTOH, you might be better served (no pun intended!) by upgrading to a multi-processor motherboard if that is the case - it would retain the benefit of local data access.

This is already in place.

>Of course, if the database is an RDBMS like SQL Server, having a separate machine is a definite advantage.

Yes, for large projects, or should I say large loads, I guess going with SQL Server as the backend would be the way to go. But, I've seen VFP apps supporting up to 250 users and so on. But, I guess the ability to respond with .2 to .25 second would be affected greatly by moving the data on one server outside of the server apps. For a desktop app, it wouldn't be a major factor but for a Web app responding at several hits a second, I guess that structure has to be taken with care.