Since with each new user/connection you're running a new instance of VFP, its engine can't be the "bottleneck" per se - you have as many engines as users. Of course, your app would need to be carefully coded to minimize contention.

When you're hitting one or more TSs that hard you'll need to pay close attention to MS's tuning recommendations, and you may have to modify default W2K settings such as maximum number of file handles, etc. IIRC I looked at this once and MS seems to have some pretty good information on tuning TS.

Yes, you can cluster servers but ultimately, with a VFP database you're still working against a single drive array for a given table or tables (it might be possible to put different tables on different drives/arrays to improve performance). You might find that disk subsystem performance is the ultimate bottleneck. You might also have to use gigabit Ethernet to minimize network latency in a cluster.

>Thanks for the suggestions. We've been working on a plan to test our application under that kind of load, but it takes some work to accurately simulate 300 or so users ringing up sales, etc. I'm not too worried about the application logic choking, or the hardware being underpowered (you can always cluster the servers or add more RAM) I'm more worried that we'll run into a bottleneck with the VFP database engine under very heavy load. I'm starting to think we need to talk to someone at MS to get some hard data on this.
>
>>There is no inherent limitation on transaction processing capacity in VFP. You run it on faster hardware, you get more transactions per second.
>>
>>I can't offer any real world experience. It sounds like you already have significant experience with TS. If so, you could track your existing 75-user server and check various loads - CPU, RAM, disk etc. This will give you some idea how much hardware you'd theoretically need to handle quadrupling up to 300 users - then you can see if that hardware exists.
>>
>>You might be able to do some testing when (if) your existing server is at low or no load. Create a test app that uses a timer to generate representative (i.e. demanding) transactions against a test VFP database. Run a few instances of that on your server and you can easily simulate any transaction load you'd like.
>>
>>Or, if a vendor wants to sell you a hot box to support 300 users, you could take that test app in and run it before you buy.