Don't be blind when making adjustments for performance. Measure, measure, measure.
New Relic is a great product for monitoring the peformance of your application. They provide performance management for Ruby, PHP, .Net, Java and Python. Today's presentation is going to focus on Ruby and specifically Rails, however, the basic New Relic overview will be applicable to any of the platforms mentioned. Integrating New Relic into your Rails application is as easy as signing up and adding the gem to your Rails application's Gemfile.
When measuring performance in the browser or on the server New Relic provides Apdex scores. Apdex is
While New Relic provides end user performance monitoring and metrics, today we're going to focus on application server metrics. You can see that End User performance measures a few different facets:
- Request queueing
- Web application
- Network
- DOM processing
- Page rendering
You can also see your performance broken down by geography, individual pages, and different web browsers.
As a Rails developer you may be responsible for both frontend and backend code, since we're all Ruby developers we're going to focus on the backend or app server metrics.
You can see requests broken down by three different facets:
- Ruby
- Database
- Web external
The Apdex score is charted over the period of time along with the throughput of the application. You can easily compare average response time, apdex score, and throughput with yesterday and the previous week.
It is also very easy to adjust the time period that you wish to analyze.
Currently we do not use New Relic for capturing errors, so this section of our overview dashboard is blank.
There is a configuration option that can be used as a threshold for determining slow requests. These requests are summarized on the overview page and can be drilled into further using transaction traces.
The map provides a brief overview of where you application is spending the most time. This can be useful to give a high level overview into your application performance.
The web transactions tab provides insight into individual controller actions in terms of a Rails application. You can look at these transaction in a variety of ways:
- Most time consuming
- You can see we spend most of our time performing job searches, which makes a lot of sense seeing that we're a job board for veterans.
- While these requests may complete very quickly, they are good places to optimize for improving the overall throughput of your application.
- Slowest average response time
- While slowest average response time can be useful, it can also direct you to places that are very infrequently used in your application, which may be less important to optimize.
- In this particular case JobsController#indeed is only requested twice per day and is very slow. We should probably look into this action, but it's not going to have a large effect on the application's performance.
- The first action that is worth investigating in this list is Api::V1::CandidateSearchesController#index. The average response time is very slow and it also is requested more often than the previous actions.
- Apdex most dissatisfying
- Highest throughput
- When to use one versus the other
- Default scope on organization.name, causes indexes to not be used on most queries
- Default scope is typically a bad idea no matter what.
- In this case we always want the listing to be ordered alphabetically by name.
- Might be worth creating a new scope called
Organization.ordered_by_name
- Using include to reduce number of overall queries
- Joins can get ugly / denormalize
- Summary tables are an awesome tool building reports quickly.
- You might think of them as a long-lived cache.
- Similar to data warehousing, analyze the granularity of the data you're reporting on and the dimensions to break things down by.
- TODO: Add example here
- Pros
- Fast reads
- Writes / updates in the background
- "Real-time" analytics
- Cons
- Not a single version of the truth
- Data can get out of sync
- Inconsistent results
- Traditional - Built into Rails
- Fragment caching on search facet sidebar - redis
- Action caching for front page stats - redis
- Page caching, does not ever hit the Rails stack, served by the web server
- Non-Traditional - Not specific to Rails
- Caching web service results like Google lat/long
- Redis / data structure "caching"
- Relieves pressure from the primary database
- Don't use a screw driver when you need a hammer
- Redis - lists, sets, hashes
- Monitoring and metrics
- Cache-hit ratio
- Cons
- Cache invalidation is hard
- Don't rely on a cache to fix performance problems
- How slow is your site when the cache is cold?
- The facet sidebar
- Biggerpockets sidebar
- Events page, fetching organization job listing
Record video showing different sections of new relic.
Summary tables