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 uses GC::Profiler.total_time and it must be enabled with GC::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

• Fix DelayedJob callback
• Limit exception message to 1 millions chars
• Fix issue #28 when for Rodauth authentication

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