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.
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.
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.
