http://docs.openlinksw.com/virtuoso/tpcc.html TPC C Benchmark Kit OpenLink Virtuoso Universal Server: Documentation virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com 2008-11-25T00:17:53Z OpenLink Software Documentation Team http://docs.openlinksw.com/virtuoso/../images/misc/logo.jpg http://docs.openlinksw.com/virtuoso/tpcctestdb.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Building the Test Database 2008-11-25T00:17:53Z Building the Test Database To build a 1 warehouse test database (approximately 100 MB), go through the following procedure: Start the database server. Assuming the server is listening at the default port of 1111 on the local host execute: http://docs.openlinksw.com/virtuoso/tpccusingtestprg.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Using the Test Program 2008-11-25T00:17:53Z Using the Test Program The tpcc program simulates one user making random transactions according to the specified mix of: Each instance of the test program has a home warehouse on which it does most of its operations. If there are more than one operation the test program will give a supply warehouse different from the local warehouse to 10% of new order lines. The test is started with: http://docs.openlinksw.com/virtuoso/tpcctuningparams4users.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Tuning Parameters and Number of Users 2008-11-25T00:17:53Z Tuning Parameters and Number of Users You may run several instances of tpcc, each representing one user. You will see CPU utilization improve as users are added since there are more possibilities of interleaving I/O and CPU. The amount of RAM (number_of_buffers: in wi.cfg) is the single most important factor influencing throughput. Setting this to about half the system RAM is usually good. One will remember that each buffer takes 8.5K of actual RAM. One should be careful not to cause the server process to swap. Striping should be used if there are multiple independent disks, one stripe per physically independent volume. Each stripe should have its own I/O queue. If there is a RAID, then striping is less beneficial. Also one should have multiple handles per files, see FDSPerFile in the configuration file. http://docs.openlinksw.com/virtuoso/omissionsexcp.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Omissions, Exceptions from the Definition 2008-11-25T00:17:53Z Omissions, Exceptions from the Definition Running the benchmark by the book is a complex and costly process which requires hardware and software that is not commonly available. To measure tpmC rates that are directly comparable with published figures the benchmark must comply with the scaling rule of a maximum of 12.5 tpmC per warehouse. Therefore to measure 1250 tpmC, one must have a database of 100 warehouses, approximately 10 GB. Obtaining a good figure will require the maximum RAM configuration of the platform in question. http://docs.openlinksw.com/virtuoso/sampleconf.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Sample Configuration 2008-11-25T00:17:53Z Sample Configuration This section describes how to set up disks and I/O for a sample run. To begin with, the scaling rule is 12.5 tpmC per warehouse. This means that in order to measure 1000 tpmC you must have a 1000 / 12.5 = 81 warehouses. These take about 100 MB apiece. The benchmark's working set consists of the STOCK and CUSTOMER tables of each warehouse and of the ITEM table of the database. Other tables are accessed more or less sequentially, i.e. inserts to end or deletes from start. There is a particular distribution of hits for the STOCK and CUSTOMER rows of each warehouse, leading to a specific working set within each. The 160 day rule requires a disk configuration sufficient for accumulating 160 days worth of transactions at the reported rate. For practical reasons we will ignore this rule here. To just run the benchmark for the required 20 minutes we will need about twice the space of the initial data. Let's assume we have an initial database of 8 GB and have another 16 GB for working space, a total of 24 GB. This is 6 4 GB disks or 12 2 GB ones. http://docs.openlinksw.com/virtuoso/otherfactors.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Other Factors 2008-11-25T00:17:53Z Other Factors Benchmarks are run with a transaction monitor, usually Tuxedo. This has not been discussed here. Multiprocessor questions have not been addressed either. Virtuoso off the box should scale to about 4 CPU's on any appropriate multithreaded, multiprocessor OS. Past 4 CPU's the returns will diminish. Operating systems have different caching policies which must be taken into account. If an OS does read ahead, that's OK. Generally OS intelligence is harmful and should be turned off. For example, AIX reacts to its disk write queue being full by turning off the writing process until it has flushed enough of its own file cache. This instead of blocking the writing thread and leaving the rest of the process to run. We may release more information on OS tuning in the future. http://docs.openlinksw.com/virtuoso/tpccprocs.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com TPC C Procedures 2008-11-25T00:17:53Z TPC C Procedures http://docs.openlinksw.com/virtuoso/ddlstmt.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com DDL Statements 2008-11-25T00:17:53Z DDL Statements http://docs.openlinksw.com/virtuoso/storedprocs.html virtuoso.docs@openlinksw.com virtuoso.docs@openlinksw.com Stored Procedures 2008-11-25T00:17:53Z Stored Procedures