In order to judge the overall results of JDBC drivers performance is just one criterion. Likewise important are factors like stability, reliability and a complete implementation of the JDBC 2 specifications (including the so called optional package - e.g., distributed transactions with two-phase commits) are particularly important for superior performance under real life conditions.
The following test demonstrates very clearly why thousands of clients and more than 500 OEMs in more than 70 countries rely on JDBC drivers from i-net software. After examining the drivers from our competitors we are sure that we offer the best value available on the market. In addition, we offer professional and responsive support for our JDBC drivers. If you have any questions please contact our support team.
In order to provide you with a meaningful test, all data types for Oracle were used in the test table resulting in some severe problems for some drivers.
Since other vendors' license agreements do not allow us to publish benchmarks you'll have to do them by yourself. We provide everything for a meaningful testing on our web-site. If you have any questions please do not hesitate to contact us.
| file date | SEROPTO 1.15 27. Apr 02 |
|---|---|
| 1 classicStdInsert() | 246,755 ms |
| 2 getAll() | 16,544 ms |
| 3 preparedInsert() | 250,140 ms |
| 4 getNumbers() | 2,934 ms |
| 5 getReals() | 2,894 ms |
| 6 getDates() | 3,335 ms |
| 7 getText() | 3,185 ms |
| 8 getBinaries() | 2,864 ms |
| 9 getNumbersFromScroll() | 17,765 ms |
| 10 getRealsFromScroll() | 16,584 ms |
| 11 getDatesFromScroll() | 17,956 ms |
| 12 getTextFromScroll() | 19,800 ms |
| 13 getBinariesFromScroll() | 18,977 ms |
| 14 lobInsert() | 4,156 ms |
| 15 getBlobs() | 480 ms |
| 16 getClobs() | 501 ms |
| 17 getBlobsFromScroll() | 781 ms |
| 18 getClobsFromScroll() | 521 ms |
Please note: The comma in the numbers represents a thousands delimiter, i.e., 90,900 ms is ninety thousand, nine hundred ms.
| Server | Client |
|---|---|
| Windows NT Server 4.0 SP6 Oracle 9i, charset WE8ISO8859P1 512 MB RAM PIII 866 100 MBit | Window 2000 Server SP2 JDK 1.3.1 128 MB RAM PII 333 100 MBit |
Why were the tests applied in one setting? Because if the tests are applied separately, then they are much faster (up to 50%). Why is this so?
Answer: The largest performance problem in a java application is the Garbage Collector (GC). If you execute every test separately like other benchmark tests then you would ignore this important factor. If you execute all tests together in one context, then and only then a real application has been simulated. That is to say that the interpretation of a performance of a single test does not make sense since it is misleading, i.e., all tests interact with each other.
You can download the sources, classes and batch files to verify the results. The driver you need has to be downloaded from the vendor's sites.