Hammerora

Hi,

Yes the warehouse assignment code is random so you can end up with multiple users per warehouse. The main question is are you using keying and thinking time to simulate what takes place in a real TPC-C type test or are you running with keying and thinking time turned off? If keying and thinking time is turned off even a single user has the ability to drive a a significant amount of CPU load on the system under test therefore in this case the combination of for example 200 warehouses and 500 users is a mismatch. For a fair random assignment I would recommend at least 4X warehouses to users at the peak and this will limit any row lock contention however when keying and thinking is off it is a common error to over allocate users. To compare different platforms there is some instructions here http://hammerora.sourceforge.net/tpc-c.htm I recommend starting at 1 then working up 2,4,8,12,16,20 etc whilst monitoring the AWR report and the CPU load on the target (and the testing ) server. This way you can map the performance in a spreadsheet and also pretty accurately assess where the curve will flatten out against the number of users and the system under test is at 100%. With this sort of workload against a typical 2 socket quadcore system (without knowing too much about your configuration) will be about 50 users so at the peak you shouldn't see any contention and therefore not need to modify the test script. if your system is bigger start with more warehouses (I find it takes about 30 minutes for me to create 200 warehouses on a 2 socket quad core) but still start at 1 thread and build a profile. Of course this sort of intensive test doesn't give all the picture of scalability and therefore the keying and thinking time test with more but slower users (eg 17 seconds between transactions) is useful too but the intensive test will give you the best initial feel for a systems potential in the shortest space of time. You can then use this as a base reference for further tests.

Cheers,

Steve