At work, Ryan shared this post about getting Eventstore running on Google Cloud Platform (GCP) to try out on Azure. Now for those of you who don’t want to read the entire other blog post, what it talks about is setting up a Eventstore cluster in two ways
Cluster using Pod local storage - where if the pod goes down, you lose all data and when Kubernetes brings up another pod, it will have to catch up.
Cluster using a GCP persistent disk - where the nodes write to external storage on a persistent disk so that when a pod goes down, the storage is still intact and the new pod can just use it.
Setting this up in Azure was pretty trivial. The pod version is exactly the same however, for the persistent disk we use an Azure file share
After I got this setup, I wanted to see the difference in performance between the two clusters. My inkling was that the pod version should be faster since it’s accessing local storage vs the persistent disk which has to do SMB 3.0. However, the disk version should pull ahead when pod failures occur since it does not have to catch up with the cluster. While that was intuitive, it helps to validate it and to know how much the difference is really.
Eventstore has a pretty simple REST api - so my test involved creating a stream, adding
10 events to it then reading the entire stream and then reading each event individually.
So in all, each test is 21 requests - 10 writes and 11 reads.
The test script is in js (ES6) and
src/test.js - the test tool is k6.
I picked k6 since it’s in Go - so single executable and the scripts are in js so
writing a little script like this was quite easy.
Now it was just a matter of running the scripts - I ran 4 tests against each cluster:
No real surprises though - to summarize - In the first two tests, the pod version does about 25% more requests/sec. In the third, this drops to 12% (but this could well be due to the client).
The fourth is where there was a surprise. I expected the File Store version to be significantly ahead on this one and it turns out that it’s not so much.