>>Do you mean by CPU a virtual CPU (i.e., one process)? If so, 10 users per process is very good. That seems to be what you are describing. If so, that's very good. I typically aim at 3 users per process (in a highly transactional system that does a lot of reports that need crunching).
>>
>
>He mentioned earlier it's by CPU core (not process). Since they're effectively running VFP that isn't too bad - VFP is a CPU hog. But it's highly dependent on the type and usage of your VFP app anyway - lots of queries / reports means higher average CPU usage, which then limits the # of concurrent users per core. I'd bet you could get a lot more if the typical usage was just data-entry.

As you write, it depends, yes and no; we'll probably be able to draw app categories later and compute average # of concurrent and non-contending users per CPU. What we know better now are the ratios between named and concurrent users.

Data entry also takes a lot of processing power because it requires a lot of user event; eg. each time user moves to another control, we often have a .valid() firing and, sometimes, a .gotFocus().

As a web server is stateless, each user request requires restoring and saving its state, which takes between 200 and 300 ms depending on the form's complexity.