I'm drinking a beer while watching my Kadira dashboard. CPU usage is less than two percent, and life is good.

We launched the meteor version of Edthena in August of 2013. At the time, our app appeared stable to our users, however I had serious concerns about scalability. With even a handful concurrent connections, our CPU usage was regularly over twenty percent. We followed many of the best practices and made educated guesses about what we could improve, but we did not have a clear picture of what was going on inside our app. I now affectionately refer to this period as the dark ages.

With the introduction of oplog tailing, along with a lot of trial-and-error, we managed to dramatically increase our overall performance, however we still had no clear idea of what we could improve upon or what, if anything, was broken on the client.

In June of 2014 we started experimenting with Kadira. After reading through the academy articles and playing around with the service, it was obvious that this was the tool we needed. In the following sections I'll give some anecdotal evidence of Kadira's explanatory power.

Subscriptions

Right after we got familiarized with the interface, it was clear that our subscriptions were not optimized. We were using iron router to subscribe to publications, only to tear them down an re-subscribe moments later. In our case, the solution was simple. We identified the recurring subscriptions and cached them using Subscriptions Manager. The result: a more responsive site with less CPU and bandwidth usage.

Network Latency

One of the many ways you can improve your app is to send less data to the client. A great way to figure out which subscriptions are eating up bandwidth is to sort them by
network latency. In our case, the big winner was not only three times the size of our the next-largest subscription, but it was also requested as soon as the user logged in. After a few fixes, we are now publishing only ten percent of the original data and users have a much faster initial page load.

Livelock

We recently found that after pushing several changes to production, something was bringing the server to its knees. It turned out to be a simple livelock scenario. The server updated the user's profile which was tracked in an autorun on the client. Under certain circumstances, the client would then update the profile and the two would enter a death spiral. Instead of looking through hundreds of lines of code to find the problem, Kadira showed us exactly which method was running excessively and we pushed an immediate fix.

Client Errors

As part of our migration to meteor 0.9.x, I rewrote several of our internal packages. I accidentally broke the API to our modals package which was needed in our analytics tracker. After the release, we noticed that recorded pageviews went to zero. Because Kadira now has the ability to track client-side errors, once again it was as simple as visiting the Error Manager console to locate the source of the problem.

These are just a few of the many ways we use Kadira on a daily basis to improve the Edthena app and our users' experience. I highly recommend giving it a try.