Instrumenting the performance of custom code (the code you write, not the libraries you require) in web apps has been a thorn in my side for years. Yes, we have a custom instrumentation API, but raise your hand if you enjoy sprinkling your code with this? Anyone? Having a custom code instrumentation blackhole doesn't matter if your app spends almost all of its time in common libraries that Scout instruments by default (ex: ActiveRecord, Redis, View Rendering, and HTTP calls).

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).

Python performance measurement tools help us to identify performance bottlenecks in our app. This allows us to focus on the business logic as opposed to writing custom code, setting it up with our app, and then figuring out whether the results are accurate enough. These tools are well tested by the open source community and used by many companies to measure the performance of their web apps.

Imagine this: your library is trying to step up its game and compete in the Internet age. Rather than you browsing the shelfs, trying to remember how the Dewey Decimal works, you'll enter your book selections from your phone. A librarian will then bring your books to the front desk. You place your book order on a busy weekend morning. Rather than getting all of your books, the librarian just brings one back.

Last month we talked about the PHP monitoring landscape in 2019 and announced that Scout APM would soon be available for monitoring your Laravel applications too (as well as your Ruby, Python and Elixir apps of course!). Now that our PHP monitoring agent is ready for beta testing, we thought it would be a good idea to show you folks how easy it is to get started with it and to highlight the main features to the Laravel community.

We are happy to announce that Scout now integrates with the popular error monitoring solution, Honeybadger. This integration brings a similar feature set to our existing Rollbar, Sentry and Bugsnag integrations, and it allows you to see your errors and exceptions alongside your performance metrics all on a single page. So let’s take this opportunity to take a closer look at Honeybadger and see how you can get it setup within Scout in just a few minutes!

One of the joys of using the Ruby language is the many different ways that you can solve the same problem, it’s a very expressive language with a rich set of libraries. But how do we know which is the best, most efficient, use of the language? When we are talking about algorithms which are critical to the performance of your application, understanding the most efficient approach to take is essential.

There is no doubt that looking at response times and memory usage is essential to understanding the general health and performance of your application. But as I am sure you are aware, there is more than one way to monitor an application. Approaching monitoring from a different angle can be a powerful way of gaining new insights. If all you did was watch for high response times or areas of memory bloat, then you might overlook something far more simple: the user’s general level of satisfaction.

July 09, 2019 With the official release of Rails 6 just around the corner, we round up all the major new features coming your way. It is an exciting release due to some big features coming upstream from the Basecamp and GitHub projects. Amongst the many minor updates, useful tweaks and bug fixes, Rails 6 will ship with two completely new frameworks: ActionText and ActionMailbox, and two big scalable-by-default features: parallel testing and multiple database support.

July 08, 2019 In this post, we will walk through various techniques that can be used to identify the performance bottlenecks in your python codebase and optimize them. The term "optimization" can apply to a broad level of metrics. But two general metrics of most interest are; CPU performance (execution time) and memory footprint. For this post, you can think of an optimized code as the one which is either able to run faster or use lesser memory or both. There are no hard and fast rules.