The Tokyo Scout team attended Rails Tokyo #37, a Rails focused get-together that is open to any Rails topic. It was hosted at the Cookpad office in Tokyo, which has some of the best Rails engineers in Japan. In this large open area there were tables, a screen for presentations and a large kitchen island. At these Cookpad events, Cookpad provides an extensive meal prepared in house by a chef!! After a great meal, we got into the presentations. The presentation titled "Database Performance for Ruby on Rails Applications" really caught our attention because this is right down our alley. The presenter discussed the importance of having an APM to keep everything operational… A serious coincidence!! One of the first events that Scout team in Japan attended talked about application monitoring!!
What is Falcon?
The GitHub Readme describes Falcon as, "... *a multi-process, multi-fiber rack-compatible HTTP server ... Each request is executed within a lightweight fiber and can block on up-stream requests without stalling the entire server process."*
The gist: Falcon aims to increase throughput of web applications by using Ruby’s Fibers to be able to continue serving requests while other requests are waiting on IO (ActiveRecord queries, network requests, file read/write, etc).
Wagtail is a fast, modern opensource content management system built on Django. Used at NASA, Google, MIT, and more, it's a great option for running your own CMS. When we add the
scout-apm package to the app, we'll quickly gain insights on the app's performance.
I'll start with the performance monitoring basics, then move onto advanced settings we've found valuable for monitoring our own apps at Scout.
I don't know of an easier way to deploy a Django app than letting Heroku do the work. That said, how do you stay on top of your app's performance, errors, and stability post-launch? Running an app on Heroku is a blissful experience, but it presents some monitoring challenges that aren't present when you control the hardware.
In this post, I'll walk through a free-to-start, low-effort approach that gives you great visibility of the health of your Django app on Heroku. All of the services below either have Django-specific support or don't require a significant time investment to work with a Django app.
Most scientific papers are unlikely to change your day-to-day approach as a Rails web developer. How not to structure your database-backed web applications: a study of performance bugs in the wild Yang et al., ICSE’18 is the exception to that rule.
This study examined 12 popular, mature, opensource Rails apps for ActiveRecord performance anti-patterns. And boy, did they find some issues:
11 out of 12 studied applications contain pages in their latest versions that take more than two seconds to load and also pages that scale super-linearly
Once your Rails app begins seeing consistent traffic, slow SQL queries will likely rear their ugly head. Simple things like using find_by_sql can make a big improvement, but how can you easily tell where your app is slowing down?
While PostgreSQL and MySQL can log slow queries, it's difficult to gleam actionable information from this raw stream. The slow query logs lack application context: where's the LOC generating the query? Is this slow all of the time, or just some of the time? Which controller-action or background job is the caller?