Hi Hank,

Not sure about the difference between a process, a CPU and a core.

The table below shows that with 6 COM servers (processes, hence the ProcessID in leftmost column) running load-base (request go to the first available process), the 6th server (PID 4292) runs only 3 requests out of nearly 10k (.03%). In this (very comfortable) situation no contention ever happens.

If we had 3 processes instead, 102 requests (85+14+3, 1%) would fall in contention for an available process, meaning that these users, 1% of the cases would wait for an additional average response time, .6 sec. in this case.

It means that, if 2 processors would theoretically be enough to serve our 15 concurrent users, at least 3 are necessary to ensure almost no contention (no wait queue) for processing capacity.

The time frame analyzed (morning) is, for this business, dedicated to order entry with some printing: order confirmation for the patient, work order for the lab; data analysis comes mostly in the evening, when the day's statistics are drawn.

Regarding this discussion, I would add that the number of users per processor is of very little importance for data analysis and reporting (BI): whether users wait for 20 or 25 seconds to get a report has very little impact on the perceived performance.

By contrast, when performing order entry at front desk like in this case, each patient (customer) requiring at least 20 hits on the system (20 user events), response time makes a lot of difference.

Also the cost of hardware available today is just not an issue. The server used by this application is of 3-years old, lower-end Intel technology;
using the latest high-en Intel Xeon would simply cut all figures by half, making all this discussion of how many users per CPU just OT.

>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).
>
>
>>>>

>>>>PID    COM server    hits
>>>>5744  ctb.ctbServer	  6996
>>>>5564  ctb.ctbServer	  2284
>>>>4648  ctb.ctbServer	    548
>>>>4312  ctb.ctbServer	      85
>>>>424	  ctb.ctbServer	      14
>>>>4292  ctb.ctbServer	        3
>>>>total                           9930
>>>>

>>>>
>>>>around 1 hit per second
>>>>
>>>>10 users average
>>>>250 hits per user per hour
>>>
>>>I don't really know what you want to say with these stats. Are you saying the server is under heavy load and thus justifies the 10 user / max CPU usage? I don't know what a "hit" entails, what resources a "hit" uses. But 10 users = max CPU seems very onerous imo.
>>>
>>>The server I described also acts as a web server serving remote requests for data directly feeding into end-user spreadsheets. It handles millions of data records in the charting databases, tens of thousands of records in multiple reporting databases, etc. It easily handles 20, 30 or more users. And I don't think it is a very high end server; just a single CPU, 16Gb ram. I could easily ramp that server up.
>>>
>>>What is consuming the CPU on your service? Is it FIC or the database engine or what?
>>
>>Frankly I'm not very keen at discussing whether it seems or not
>>
>>We have dozens of response time figures to share, for readers who like to analyze real facts and figures, are you one of these?
>>
>>Speaking of millions, the database has million records (order items)
>>This application is an ERP that the whole company works with.