There’s my heroku bill after hosting the voting for a local television contest. $2.37. Over 40,000 people used the app over a period of 2 weeks.
I spent the same amount on coffee this morning.
I’ve always been really interested in scaling and getting the best possible performance out of limited resources.
I had the opportunity recently to build out the voting back-end for a local television contest. Projects like this are fun because I had the flexibility to try out something new and a lot of people would be using it.
I wanted to build an API to handle the voting and get the best performance out of it. Usually I’d use Sinatra for this, but this time I chose to try out Goliath, which is a non-blocking Ruby web server for building APIs. I also used Grape since it would make writing the API even easier.
I hosted it on Heroku. My initial goal was to see if I could keep it to only 1 dyno (more fun with a challenge).
If you’re not familiar with Heroku, a dyno is the equivalent of a small virtual server with 512mb of memory. They also give you your first dyno for free. So all I ended up paying for was the postgres basic database add-on.
Before releasing it, I did some stress testing with Siege. I couldn’t have this app failing when it went live.
212.45 transactions per second.
On only 1 heroku dyno.
WOW GOLIATH IS FAST.
Each transaction was a single GET request, that hit the database (postgres) and returned the count of contest votes. Postgres was probably the slowest part of each request. I could optimize even further by caching with memcached. Maybe next time.
The 200+ transactions per second was way more speed than I needed for this app. And much more than I expected to get out of a single dyno.
I knew that the traffic for this app would be pretty sporadic. Highly dependent on when it was mentioned on TV. Without Goliath, I would have needed to use more dynos to account for the spikes in traffic. But with the performance I was seeing out of Goliath, I knew it could handle the peaks with just 1 dyno.