Today we started looking into options for creating our back end API, which will be used to log the information we track about's visitors. The back end will receive the data using RESTful routes. This gives us a lot of flexibility, since REST is a standard implemented by basically every web framework out there. Four frameworks came to mind as feasible:

  • Express.js (running on a Node.js web server)
  • Rails API
  • Good old, plain PHP (running on an Apache web server)

I love the sheer speed at which a developer can prototype and deploy things with Ruby on Rails, and my team mate has a strange love affair with JavaScript. However, we aimed to be objective and not choose to use one programming language or framework simply because we anecdotally liked it. We decided to benchmark. Spoiler alert! I, for one, welcome our new JavaScript overlords. :D

We looked at the number of transactions per second the back end could accept, where a transaction was a request that involved accessing a database. We didn't have time to properly test all the options (Rails was tricky to get set up), but some specific Express.js vs. PHP results so far can be found on my team member's associated blog post. In summary, we found that Express.js on Node.js ended up being incredibly fast, even faster than we thought it would be at first. We actually expected Apache with PHP to be quickest. We thought of it as the "C" of web programming languages. It's simple and low level. It ended up being the slowest and the quickest to fail when the number of concurrent requests grew.

We didn't get around to testing ASP.NET (and to be honest, we think we'll ditch it anyways since we want to stay open source), and Rails API ended up performing somewhere in the middle. However, Rails needs to be further tested since we weren't able to get it fully set up to take advantage of multiple CPU cores or even access the database. In all cases, we tested these against a PostgreSQL database. We strongly believe we'll end up going with PostgreSQL because of its reputation as a powerful, stable, open source option.

We still have much to do here. We need to create realistic benchmarks. Real users don't click on things or scroll their mouse wheel thousands of times per second. We need to create benchmarks that reflect the way people read articles online and engage by commenting, sharing, etc. Preferably, they would reflect the way visitors visit the site. Perhaps we'll continually benchmark as we gain information by starting to monitor the users and make the benchmarks more accurate over time.

Note: This was originally posted on the blog I used for my co-op term while at Seneca College ( before being imported here.