GG.deals is hosted on DigitalOcean. Although choosing DigitalOcean for hosting was pretty straightforward for us, we were still not so sure if it is worth pay extra for CPU-Optimized droplets. CPU-Optimized droplets obviously should be more efficient in CPU-intensive task, but there was no real comparison of how more efficient they are. But we get some comparison when we tried to perform database migration from Salenauts to GG.deals on two types of droplets.
Migration of database from Salenauts to GG.deals was quite an intensive task. GG.deals completely changed the way how prices info was stored in the database, and Salenauts already had prices history for hundreds of thousands of products for more than 4 years. We created a migration script which coverts old data to fit new schema, but we never really optimized it. As a result, we get single-thread migration script which needs to convert billions of entries into a completely new format (which requires calculating some statistics).
This was not a big problem as long we were using CPU-Optimized droplets for the database server (4 vCPUs, 8 GB RAM, $80/mo). The main part of the migration takes about 5 hours, which was long, but still acceptable. This becomes much worse when we tried to use Standard droplet (4 vCPUs, 8 GB RAM, $40/mo) – the same migration now takes 20 hours. That’s right, in our case CPU-Optimized droplet was 4 times faster than Standard droplet.
Obviously, this is something closer to anecdote than a real comparison – in your case difference may be smaller or even unnoticeable. But this example learned me two things:
- Always test such operations before running on production. Test migrations before real migration saved us huge fuckup with unacceptable long downtime because of too slow (or too small) database server (yeah, it did not save us from all fuckups, but it could have been worse 😛).
- CPU-Optimized Droplet vs Standard Droplet is not only about “how many queries or requests per dollar I can get”. Sometimes it is more important “how fast” than “how many” – in our case shorter downtime and lower TTFB was a priority and wasting 20 hours on migration on Standard droplet was no go.