Profiling memcached, redis, RPC time

1

Have you considered being able to add custom columns to the profiler results screen for other types of service usage?

alt text

I’d love to be able to show things like RPC calls + time, redis requests + time, and memcached requests + time. The existing SQL column feels like a perfect template for displaying this information. I imagine additional columns filling in to the right of the SQL one.

We’ve just set up rack-mini-profiler on a new project and are really loving it. We have a custom (and admittedly pretty hacky) solution we call the “mission control bar” for github.com and, while its not general purpose at all, it does give us a bit more visibility into other external services. I’d love to replace it with rack-mini-profiler so we had something we could easily plug into all of our apps.

I haven’t dug too deeply into the codebase. I’m wondering, are there existing APIs that’d let me accomplish something like this? Or plans to add them? If not, would you be interested in pull requests that experiment with such a feature?

2

I follow, back in a previous life, in a previous profiler we had this concept of “sub steps”, the idea was to have light weight counters that aggregate times, just as you describe.

I would love to see this kind of support in MiniProfiler as well.

The concept would be to add say:

Rack::MiniProfiler.counter("counter name") do 
  # stuff goes here 
end

Then the UI can have special handling for counter steps, and add the column dynamically. I think this will work fine, but am a bit concerned about what happens when there are say 50 different counters, the UI will get terribly wide. I don’t think this is blocking though, we can figure out a solution once we have that problem.

We also need to be extra careful implementing the counter API, as this is meant to be extra light weight.

Love the idea, and would be more than happy for you to work on it in a fork.

Word of warning though, I think it is time for some prep work to add a proper object model for the mini profiler data, at the moment it is using a really odd object semantics that is a relic of the mini profiler ruby prototype.

Every time I see code like this I cringe:

def initialize(name, page, parent)
    super("Id" => MiniProfiler.generate_id,
          "Name" => name,
          "DurationMilliseconds" => 0,
          "DurationWithoutChildrenMilliseconds"=> 0,
          "StartMilliseconds" => (Time.now.to_f * 1000).to_i - page['Started'],
          "ParentTimingId" => nil,
          "Children" => [],
          "HasChildren"=> false,
          "KeyValues" => nil,
          "HasSqlTimings"=> false,
          "HasDuplicateSqlTimings"=> false,
          "TrivialDurationThresholdMilliseconds" => 2,
          "SqlTimings" => [],
          "SqlTimingsDurationMilliseconds"=> 0,
          "IsTrivial"=> false,
          "IsRoot"=> false,
          "Depth"=> parent ? parent.depth + 1 : 0,
          "ExecutedReaders"=> 0,
          "ExecutedScalars"=> 0,
          "ExecutedNonQueries"=> 0)
    @children_duration = 0
    @start = Time.now
    @parent = parent
    @page = page
  end

The objects should be pure, cause it also reduces the string allocations of MP and makes it more efficient, the serilizer can take care cleaning this up.