https://github.com/mbajur/inner_performance
Simple database-backed performance monitoring for your Rails app.
https://github.com/mbajur/inner_performance
apm performance-monitoring rails
Last synced: 17 days ago
JSON representation
Simple database-backed performance monitoring for your Rails app.
- Host: GitHub
- URL: https://github.com/mbajur/inner_performance
- Owner: mbajur
- License: mit
- Created: 2024-11-23T10:17:43.000Z (5 months ago)
- Default Branch: main
- Last Pushed: 2025-02-21T08:41:55.000Z (2 months ago)
- Last Synced: 2025-03-30T19:08:02.897Z (24 days ago)
- Topics: apm, performance-monitoring, rails
- Language: Ruby
- Homepage:
- Size: 152 KB
- Stars: 46
- Watchers: 2
- Forks: 4
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# ☯️ InnerPerformance [](https://badge.fury.io/rb/inner_performance)
Simple database-backed performance monitoring for your Rails app.
## Installation
Add `inner_performance` gem to your bundle
```ruby
$ bundle add inner_performance
```
Install migrations
```ruby
$ rails inner_performance:install:migrations
$ rails db:migrate
```
Mount UI in `routes.rb` (don't forget to protect it!)
```ruby
mount InnerPerformance::Engine, at: '/inner_performance'
```
## Configuration
inner_performance comes with some good defaults but in order to customize
them, you have a following options available:
```ruby
InnerPerformance.configure do |config|
config.sample_rates = {
# 2% of all the requests will be stored and analyzed. I would
# recommend keeping it low because otherwise your database will
# get full of events quite fast. It will also probably impact
# your app's performance. As an example: In a Spree shop with
# approx. 170 requests per minute, keeping it at default 2%
# provides me more than enough data to analyze and locate the
# bottlenecks. Value can be both decimal and integer.
'process_action.action_controller' => (Rails.env.production? ? 2 : 100),
# 100% of all the jobs will be stored and analyzed.
'perform.active_job' => 100
}
# For how long events should be stored. All the ones that exceeds
# this limit will be cleared out by InnerPerformance::CleanupJob.
config.events_retention = 1.week
# Used mostly by UI. Tells the UI what's the middle range when it
# comes to event duration. For the example below, all the durations
# between 0 and 200ms will be considered fast, all the ones between
# 200ms and 999ms will be considered medium and all above 999ms will
# be considered slow.
config.medium_duration_range = [200, 999]
# Set it to true to enable tracing of SQL queries and views rendering
config.traces_enabled = false
# Rules for ignoring an event. There are two rules applied by default:
# * sample_rates - operates on configured sample rate and drops events
# which do not got lucky when drawing a random number
# * InnerPerformance job namespace - we don't want to save events for
# the job that saves the events because that leeds to infinite loop.
# Better not remove this rule as it will lead to stack overflow.
config.ignore_rules.unshift(
proc { |event| !event.is_a?(ActiveSupport::Notifications::Event) }
)
# Set it to true if you want to cleanup old events right after saving the event
config.cleanup_immediately = false
end
```
## Regular Housekeeping
To ensure optimal performance and avoid data bloat, remember to schedule the cleanup job:
```ruby
InnerPerformance::CleanupJob.perform_later
```
Alternatively to scheduling the job yourself, you may utilize the configuration option `config.cleanup_immediately = true`. This configuration is not as optimal so its disabled by default.
# Alternatives
* [rails_performance](https://github.com/igorkasyanchuk/rails_performance) - much
more robust but depends on Redis. Operates on `ActiveSupport::LogSubscriber`
instead of `ActiveSupport::Notifications`
## License
The gem is available as open source under the terms of the
[MIT License](https://opensource.org/licenses/MIT).