Shika performance testing & benchmarking against MS SQL Server

In our Shika beta launch post, we stated that in real-world tests, Shika has recorded read/write speeds of ~1000x faster than SQL.

As you would expect we’ve done a lot of testing and benchmarking. Here are just a couple of examples which verify our claims.

First up is a representative test of a demanding real-world implementation, writing multiple values non-sequentially to 40,000 tags. We made this deliberately tough so that every write operation involved a seek operation too. As you can see below, Shika is fast.

Shika Test Execution Time (seconds)

This example shows the overhead involved with calling Shika over a network using Windows Communication Framework (WCF).  Even with this overhead it’s still much faster than a local SQL implementation. A local Shika implementation offers the best performance.

Anyone can skew results with great hardware, but we know our customers want efficient code. So we’ve tested and benchmarked on simple machines, with these benchmarks coming from a lowly Intel Core2 Duo E7500 2.93GHz with 4GB RAM.

Shika Writes Per Second

Clearly Shika has a higher raw data handling capacity than SQL, which is what we aimed for in the first place. The fact that it’s so fast means it has many more applications which we’ll be exploring in our beta programme.

So, what next?

Firstly, we’re really interested to see how it compares to some of the other process historians out there. We know Shika starts up in a fraction of the time other process historians take but we think we can beat them on raw data acquisition and access. So we’ll be putting it alongside existing historians on beta customer sites.

Also we’d like to benchmark it on some representative machinery so we can see how fast this code can run. This will give us some great benchmarks, but more pragmatically will help us identify new ways to optimise the code.

We’ll have more Shika news soon.

 

Start typing and press Enter to search

Steam-Release-Plant