Hello @efox this is interesting and I wonder if you have similar pointers to optimising the configuration for a MySQL data store.

At the moment on a basic instance a simple query counting the number of rows in a table with 3m rows takes 1.8s on local storage vs 12seconds on block storage.

hdparm testing as above and similar results. The instance type is fine for our usage and I havent tried optimised droplets (only CPU optimised are available atm in Lon 1).

root@db3:~# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 16110 MB in 1.99 seconds = 8098.96 MB/sec
Timing buffered disk reads: 704 MB in 3.01 seconds = 234.24 MB/sec
root@db3:~# hdparm -Tt /dev/vda1

/dev/vda1:
Timing cached reads: 16454 MB in 1.99 seconds = 8273.15 MB/sec
Timing buffered disk reads: 1802 MB in 3.00 seconds = 600.17 MB/sec
root@db3:~#

Hey there,

You will always see a bit worse performance on a Volume compared to local storage, Volumes are network-based storage which adds some overhead. In our experience, it is quite possible to run MongoDB databases on Volumes with proper tuning.

We recommend testing with MongoDB as the performance can differ from using hdparm which only writes/reads one file.

With regards to these results, that speed is expected on a Standard Droplet: https://www.digitalocean.com/docs/volumes/overview/#features

We recommend Optimized Droplets for higher burst throughput, but also recommend application tests to see how non-burst performance works for your use-case. The IOPs you get can be tuned by adjusting queue depth.

Queue depth is one of those things that we always like to bring up in regards to gaining improved performance with MongoDB on a Volume. Volumes in DO are tuned to perform at 5k iops, but that’s at a high queue depth and block sizes. At a lower QD (Queue Depth), we may see fewer IOPS as additional latency is introduced. Our Engineers have tested some benchmarks by manipulating the application’s QD. At a QD of ~2, we see about 500-600 iops. But, raising that to 32, he saw that raise to ~3400 iops. It is required to tune the application to work at a higher QD and tweak the settings to increase the number of parallel writes to the disk.

On the OS level, the following file ’/sys/block/<sdx>/device/queue_depth" stores the value of QD, and you’ll need to tune MongoDB’s QD and the OS QD together to get more performance. The following blog article MongoDB’s website details a bit about Queue Depth: https://www.mongodb.com/blog/post/performance-tuning-mongodb-on-solidfire. It’s suggested as well to discuss this with your DBA or Database administrator, if not MongoDB support for the best MongoDB tuning options.

Regards,
Ethan Fox
Developer Support Engineer II - DigitalOcean