Releases: BaseSecrete/rorvswild
1.8.1
1.8.0
-
Measure easily any Ruby method:
class Model def self.foo # ... end def bar # ... end RorVswild.measure(method(:foo)) RorVswild.measure(instance_method(:bar)) end
-
Time garbage collector
A section with the kind
gc
measures how long the GC ran during a request or a job. All GC executions are added together in a single section. For each section, the time spent in the GC is substracted.It might not be listed for all requests and jobs, since the GC is triggered when Ruby is running out of memory. You can force that in development by calling
GC.start
.From Ruby 3.1 it is enabled by default via and the agent uses
GC.total_time
. Before Ruby 3.1 the agent usesGC::Profiler.total_time
and it must be enabled withGC::Profiler.enable
. -
Store requests, jobs and errors into the local profiler
Even after restarting the server, past requests, jobs and error are still viewable from the local profiler. Upto the last 100 entries are stored per type. They are stored into JSON files located in tmp directory.
1.7.1
- Fix DelayedJob name and args for ActiveJob wrappers
- Limit server timing header to 10 entries
- Print ASCII server timing in logs
- Improve widget UI
1.7.0
-
Add Server-Timing headers
Server-Timing is a HTTP header to provide metrics about backend runtimes.
It's disabled by default, and it has to be enabled for each request.
You will probably prefer to limit to privileged users in production to prevent from exposing sensitive data.
Here is a good default setup, to enable server timing in all environments and only for admins in production:class ApplicationController < ActionController::Base before_action :expose_server_timing_headers def expose_server_timing_headers # Assuming there are current_user and admin? methods RorVsWild.send_server_timing = !Rails.env.production? || current_user.try(:admin?) end end
-
Sample requests and jobs to lower our customers' bills
These parameters should be used by large volume applications only.
When the volume is significant, sending more does not improve precision and sending less does not decrease it.
More precisely, for a large volume of requests but a low volume of jobs, it makes sens to sample requests only.# config/rorvswild.yml production: api_key: API_KEY job_sampling_rate: 0.5 # 50% of jobs are sent request_sampling_rate: 0.25 # 25% of requests are sent
1.6.5
1.6.3
- Fix not git repository stderr
- Normalize SQL queries
- Ignore errors with a rescue handler (rescue_from, retry_on and discard_on)
- Update local profiler colors
- Wait for queue to start before sending deployment information