I'm an engineer by trade. I rely on intuition when investigating a slow Django app. I've solved a lot of performance issues over the years and the short cuts my brain takes often work. However, intuition can fail. It can fail hard in complex Django apps with many layers (ex: an SQL database, a NoSQL database, ElasticSearch, etc) and many views. There's too much noise.
Forecasting traffic to your web app is important for capacity planning, but generating a seasonally accurate model of your traffic is pretty daunting.
Using the right Ruby interpreter to run your programs can make all the difference. Unfortunately, it can be tough to find resources about different Ruby interpreter options, or about how to choose the right one.
We launched our Python agent a few months ago, supporting Python 3.4+. With out of the box instrumentation for Django, Flask, Bottle, Pyramid, Elasticsearch, MongoDB, SQLAlchemy and more, we covered a lot of ground!
Interested in Learning the Elixir language? Join us in this entertaining Elixir tutorial and overview. This post will spin a yarn about an ambitious wizard, Alatar, and his quest to revamp a magic web storefront using Elxir. We will observe Alatar decide on Elixir as his development platform, and follow him on the journey of learning and implementation. Along the way, he will utilize several frameworks written for Elixir (including Phoenix, Ecto, and Poison).
We've had sparkline charts of response time for a long time on our Endpoints tab, and now have extended them to the throughput column as well. Quickly isolate endpoints that are spiking with traffic, and drill down into them to diagnose. No need to hunt to see what's causing an unusual trend in traffic.
As reported on Issue #228, if scout_apm is disabled on a node via the configuration monitor = false, we don't intend to install any instruments, but a few snuck in anyway. Since the rest of the agent isn't running, they (slowly but steadily) built up recorded info, but didn't purge it, causing a slow memory leak that became clear over the course of a week or two. We've stopped the offending instruments from installing themselves when Scout is disabled.
Recently the Ecto library released a major update - Version 3.0. As part of the changes, some of the hooks that Scout relied on to capture data have changed. No longer can we hook into Ecto's logging system to extract information about queries being run, and instead we have a proper Telemetry event to listen to.
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).
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!!
