Like I said before, it really is not feasible unless you have the time, money, and the hardware you want to run this on. Apples to apples comparisons are not going to happen. If you have complex transactions, with all coding being excellent, SQL loses big time. I also believe the more records you have the better U2 will perform.
Good Luck, Looks like Tony has the time do you have the $$$$$$$? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Sunday, July 15, 2007 1:04 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData 7.1 vs. MS SQL 2005 performance Dawn Wolthuis wrote: > I searched for some appropriate benchmarks in 2002, but it looked like > all industry standards, such as TCP benchmarks would compare apples > and oranges unless comparing only SQL-based functionality and > performance of SQL-based RDBMS tools. TPC-B allowed any sort of database to take part in a transaction-based benchmark. It was sometime around -C or -D that they changed the requirements and definition for the test itself conform to relational structures, thus closing the door for any non-relational database to even take part. Talk about stacking the deck... To compare apples to apples I think you need a number of simple and progressive tests which can be configured to ensure some amount of equity. Examples: 1) A single table/file has 10 fields. Record the time to add 1000 records to the file. Do that 100 times and get an average. Do the same for 10k records, 100k, 1M, and 10M records. Scale as desired to higher numbers. 2) Using that same table with 1M records, perform a non-indexed sort by field1, by field2, by field3, etc. Do the same test with indexes. 3) Using the same 1M records, time how long it takes to update each field. That is, field 1 for all million records, then field2 for all million records, etc. 4) Create another table/file and perform join/translates to do similar sorting and retrieval. Join to file3, file4, etc, where similar files are used both in the MVDBMS and the RDBMS. 5) Do similar tests using common ODBC/OLEDB tools. Use custom code, Crystal Reports, or any other tools that might be used in the field to retrieve and update data. This test factors in how long it takes to transmit data through the native interfaces, and is thus more of a real world benchmark resembling end-user transaction time. 6) Do similar tests with N users all posting similar transactions at the same time - tests must be designed to initialize all N users, then get bench numbers, then cycle down. Test user numbers 50, 100, 200, 500, 1000, 5000, 10000, and 20000. A clear bell curve should arise and it would be interesting to see where that curve peaks for each DBMS type. 7) Test processing of data using simple subroutines / stored procedures. 8) Use triggers to simulate referential integrity and note performance of varying data volumes, transaction volumes, and concurrent users. All tests must be performed some number of times on newly initialized systems to avoid the benefits of memory caching which will remove much of the burden of disk IO in tests 2-N. Tests should be performed on the same hardware with equal memory, CPU, disk IO controllers, etc. So, I think we can devise our own tests and coordinate with RDBMS DBA types to ensure they're conducted fairly. The only thing I'm concerned about is funding. There are very few organizations who want to pay for the time to do this sort of thing - outside of the DBMS vendors themselves, and I'm afraid anything they come up with won't be portable to other MV or RDBMS platforms, and they would keep the exact tests a deep dark secret. If anyone does want to pay for it, I'll be happy to make it happen. TG@ removethisNebula-RnD.com ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CyberDefender has scanned this email for potential threats. Version 2.0 / Build 2.12.19.03 Get free PC security at www.cyberdefender.com ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
