http://docs.openlinksw.com/virtuoso/tpcc.html OpenLink Virtuoso Universal Server: Documentation virtuoso.docs@openlinksw.com Mon, 16 Nov 2009 14:26:59 GMT OpenLink Software Documentation Team webmaster@openlinksw.com http://docs.openlinksw.com/virtuoso/../images/misc/logo.jpg http://docs.openlinksw.com/virtuoso/tpcc.html OpenLink Virtuoso Universal Server: Documentation http://docs.openlinksw.com/virtuoso/tpcctestdb.html virtuoso.docs@openlinksw.com Building the Test Database http://docs.openlinksw.com/virtuoso/tpcctestdb.html Mon, 16 Nov 2009 14:26:59 GMT 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 Using the Test Program http://docs.openlinksw.com/virtuoso/tpccusingtestprg.html Mon, 16 Nov 2009 14:26:59 GMT 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 Tuning Parameters and Number of Users http://docs.openlinksw.com/virtuoso/tpcctuningparams4users.html Mon, 16 Nov 2009 14:26:59 GMT 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 Omissions, Exceptions from the Definition http://docs.openlinksw.com/virtuoso/omissionsexcp.html Mon, 16 Nov 2009 14:26:59 GMT 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 Sample Configuration http://docs.openlinksw.com/virtuoso/sampleconf.html Mon, 16 Nov 2009 14:26:59 GMT 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 Other Factors http://docs.openlinksw.com/virtuoso/otherfactors.html Mon, 16 Nov 2009 14:26:59 GMT 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 TPC C Procedures http://docs.openlinksw.com/virtuoso/tpccprocs.html Mon, 16 Nov 2009 14:26:59 GMT http://docs.openlinksw.com/virtuoso/ddlstmt.html virtuoso.docs@openlinksw.com DDL Statements http://docs.openlinksw.com/virtuoso/ddlstmt.html Mon, 16 Nov 2009 14:26:59 GMT http://docs.openlinksw.com/virtuoso/storedprocs.html virtuoso.docs@openlinksw.com Stored Procedures http://docs.openlinksw.com/virtuoso/storedprocs.html Mon, 16 Nov 2009 14:26:59 GMT