Top Banner

In order for this demonstration to make sense, here are a few important details.

All requests are ordered except for single index (unique id based) queries. All random queries are entirely random throughout the tables so that each query is unique and not just a repeated query which would falsely appear to be very fast. Queries are identical for both SQL and ZCachePro. Since the data requests are entirely random the results are slightly different each time the test is run.

The first run is SQL and ZCachePro running side by side. ZAppDB is slightly faster, but the indexing system is an upgraded version of what is used in ZCachePro. The test results vary only slightly with SQL so for the sake of brevity, the SQL test is only run twice. The third run is ZCachePro running by itself. Since internal caches are filled, this run completes in 3.1 seconds and the next run is even faster (2.97 secs).

Finally a run of 200,000 random queries is executed. This illustrates the sustainability of these numbers, averaging 5,000 requests per second. Not bad for a laptop processor!

The test system for this demo is a mini-pc using an I7-7700T Intel processor (quad-core) with 16GB of memory. What is important to notice here is the performance ratio between SQL and ZAppDB. The better the hardware the better they both perform, but the performance difference (or ratio) remains. A single test program is not enough load to see the limits of ZCachePro or ZAppDB. We have tested to >10,000 requests per second under windows, but the IP stack cannot release socket objects fast enough even with registry tweaks to keep up with demand. It turns out that performance seems to be limited by the IP stack, not ZCachePro. This is true with linux as well. Processor power, memory speed, and background system loading (ie antivirus software) obviously factor into these numbers.

There are two additional thoughts that should be kept in mind. Performance in this demonstration is an indication of low resource requirements (efficiency). This performance means that you can have the database on your server with ZCachePro, and dramatically increase system data throughput, thereby allowing your web service to perform much better. This efficiency means that you can reduce server count, server expenses, maintenance, and simplify deployment issues. ZAppDB also allows you hundreds of concurrent queries which can be critical for web services. This is an issue not easy to circumvent with SQL, and expensive... Write performance is far superior with ZAppDB. As currently implemented 50 to 100 times faster, and much faster than this when multiple tables are being written to concurrently.

One final thought. As the tables get larger the performance of SQL slows. ZAppDB performance is not affected by table size. We have seen many SQL apps that run really well until the data set grows and the system starts gradually slowing down. While there are ways to work-around this issue, they are painful.



Copyright © 2017, ZeroPoint, LLC.      Questions? Comments? Email Us.