Google Summer of Code proposal: Rack::Dtrace

[ecin]

For this years Google Summer of Code, I want to implement a set of
Dtrace [1] probes in Rack [2]. The idea is to create a profiling tool
that easily works across a number of Ruby web-frameworks and web-
servers and provide insight into a web-app's performance.
Node monitoring and management are within the problem domain as well.

The Dtrace probes can be coded into a Rack module using ruby-dtrace
[3]. This means that adding a useful set of profiling statistics to
any web-app would be as easy as uncommenting an 'autoload' line.

I posted this information on Rack's mailing list [4] as well, and
learned about Orchestra [5] and Rack::Bug [6] as a result. While
Orchestra aims to do what I propose in a platform-agnostic way,
Rack::Bug could better be described as a front-end to the information
produced. These are projects I can lean on and work with during the
summer. Orchestra provides a messaging system to facilitate the usage
of the information produced by probes and Rack::Bug serves as a
testbed consumer for the same information.

Any suggestions or comments on this idea?

-ecin

[1] http://en.wikipedia.org/wiki/DTrace
[2] http://rack.rubyforge.org/
[3] http://ruby-dtrace.rubyforge.org
[4] http://groups.google.com/group/rack-devel/browse_thread/thread/5fb8d07fcd023f3c
[5] http://github.com/brynary/orchestra/tree/master
[6] http://github.com/brynary/rack-bug/tree/master

[Jeremy Kemper]

On Sun, Mar 22, 2009 at 4:45 AM, ecin <ec...@copypastel.com> wrote:
>
> For this years Google Summer of Code, I want to implement a set of
> Dtrace [1] probes in Rack [2]. The idea is to create a profiling tool
> that easily works across a number of Ruby web-frameworks and web-
> servers and provide insight into a web-app's performance.
> Node monitoring and management are within the problem domain as well.
>
> The Dtrace probes can be coded into a Rack module using ruby-dtrace
> [3]. This means that adding a useful set of profiling statistics to
> any web-app would be as easy as uncommenting an 'autoload' line.
>
> I posted this information on Rack's mailing list [4] as well, and
> learned about Orchestra [5] and Rack::Bug [6] as a result. While
> Orchestra aims to do what I propose in a platform-agnostic way,
> Rack::Bug could better be described as a front-end to the information
> produced. These are projects I can lean on and work with during the
> summer. Orchestra provides a messaging system to facilitate the usage
> of the information produced by probes and Rack::Bug serves as a
> testbed consumer for the same information.
>
> Any suggestions or comments on this idea?

I think this is a great idea that benefits all Rails and Rack apps,
ecin. Is it a whole summer's work, though? What kind of probes would
you provide?

Perhaps you could provide some tooling support as well to make
answering common Rails/Rack performance questions easy.

What are the concrete goals you'd hope to achieve by the end of the summer?

Best,
jeremy