Google Summer of Code proposal: Dtrace probes in Rack.

[ecin]

Summary:
* The idea in question: implementation of Dtrace probes in Rack to
provide easy profiling to a large number of Ruby web frameworks.
* Project would also involve a request visualization app, to serve as
a useful example of what's capable with the probes.
* Your comments are very much appreciated.

I'm interested in implementing a set of Dtrace [1] probes in a Rack
module (similar to Lint), as a project for this year's Google Summer
of Code. These probes could then be used to track and analyze a web
app's performance, with disregard to the web framework or web server
in use for Ruby projects.

The probes would be incorporated into Rack with the use of ruby-dtrace
[2], and would provide Dtrace events for new requests coming in,
errors in the request handling, requests finishing, etc. The probes
could also be used for the monitoring and management of nodes running
Rack.

Adding the probes would likely not take up the 3 months Google's
Summer of Code allows. In fact, I've been able to modify lint.rb with
some simple probes for requests without a large investment in time.
Because of this, the remaining time would be spent working on a
visualization app that would use the probes. Imagine having a web
app's activity statistics baked right in with Rack!

I'm applying this project for mentorship under Ruby on Rails, as I
believe the benefit's evident for it as a web framework. I've already
posted up the idea on their wiki [4].

I'm hoping I can pick up a few comments from this mailing list. For
example:

- Is measuring performance on a per-request basis smart? Is it
feasible?
- Does this seem like a good idea to submit? Bad idea? Why?
- Any insight into how challenging implementing this idea could be?
- Dtrace has only been implemented on Mac OS X, Solaris, and FreeBSD
platforms. Is this too limiting?
- I still haven't found a mentor to help me through the summer
should this idea be accepted. Know anyone interested in helping out?

All opinions appreciated.

[1] http://en.wikipedia.org/wiki/DTrace
[2] http://ruby-dtrace.rubyforge.org
[3] http://github.com/ecin/rack/tree/master
[4] http://wiki.rubyonrails.org/gsoc/2009/ideas

[Yehuda Katz]

Hey ecin,

You might have noticed a recent project I've been working on called Orchestra. The idea behind orchestra is to do effectively what you're trying to do in a platform-agnostic way. The plan is for Rack::Bug, a debugging toolbar along the lines of what you're thinking, to use orchestra. However, I would really like to be able to use dtrace where it's available.

Are you interested in incorporating dtrace probes into the plans for Rack::Bug and Orchestra? I could provide more details if it's something you're interested in. The basic idea is to provide a set of standard events that would be triggered by Rails, Merb, Sinatra, AR, DataMapper, Sequel, etc, which something like Rack::Bug, New Relic, Five Runs, or whatever could listen for.

If you'd be interested in focusing on the dtrace side of things, I'd be happy to serve as a mentor for the project.

-- Yehuda

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[Ted Han]

Hey guys,

Since lint's been mentioned i thought i should mention Kevin Clark's
nit-pick project (formerly Dust:
http://rubyconf2008.confreaks.com/dust.html ) which he's described as
"Ruby Lint, sorta" ( http://github.com/kevinclark/nitpick/tree/master
). He's mainly focused on the code analysis end of things.

Depending on how one wants to architect a rack module specifically for
tracking request performance (which i do think is a good idea, and
Yehuda's Orchestra stuff is definitely headed in the right direction
there), you may find it fruitful to think about general
interoperability w/ nit-pick (since you guys are approaching the same
problem domain from opposite ends).

And again, I only said think about. A summer isn't a huge amount of
time, so best to pick something that's well scoped and hit it as hard
as you can :)

G'luck!

-Ted