pglombardo

%img{ :src => @chart_url }

pglombardo

# Here, I am define a "module" with name Ma. I also define two methods. One without "self."
# and one with. See, later on, what happens when I "include" and what happens when I "extend"
# the "module" within a "class".
#
module Ma
  # I will be able to make this method an instance or a class method of a class.
  # It depends whether I will "include" or "extend" the module in the class.
  # Note that this method, I cannot call it directly on Ma. In order for this method
  # to be useful, I have to include or extend this module within a class.
  #

pglombardo

# In the web request
def start_job(*args)
  # Log the fact that we're starting a job, and send the job with the current
  # task id
  Oboe::API.force_trace do
    Oboe::API.start_trace('job', nil, { :Async => True }) do
      task_id = Oboe::Context.toString unless not Oboe::Context.isValid
      Resque.enqueue(Archive, task_id, *args)
    end
  end

pglombardo

worker_processes Integer(ENV["WEB_CONCURRENCY"] || 3)
timeout 15
preload_app true

before_fork do |server, worker|
  Signal.trap 'TERM' do
    puts 'Unicorn master intercepting TERM and sending myself QUIT instead'
    Process.kill 'QUIT', Process.pid
  end

pglombardo

Backtrace generated 500 times with 1508 frames
Thread ID: 69872793616820
Total Time: 0.377622164
Sort by: total_time

  %total   %self      total       self       wait      child            calls    Name
--------------------------------------------------------------------------------
 100.00%   0.01%      0.378      0.000      0.000      0.378                1      Global#[No method]
                      0.378      0.000      0.000      0.378            1/301      Object#one
--------------------------------------------------------------------------------

pglombardo

You can instrument your Sinatra or Padrino app by adding the oboe gem to your Gemfile, running bundle install and adding the following code to your config.ru. Make sure to set :tracing_mode and :sample_rate accordingly.

require 'oboe'

# When traces should be initiated for incoming requests. Valid options are
# “always,” “through” (when the request is initiated with a tracing header 
# from upstream) and “never”. You must set this directive to “always” in 
# order to initiate tracing.
Oboe::Config[:tracing_mode] = 'through'

pglombardo

# Taken from: http://stackoverflow.com/a/6318491

require 'rack'

app = Proc.new do |env|
  headers = env.select {|k,v| k.start_with? 'HTTP_'}
    .collect {|pair| [pair[0].sub(/^HTTP_/, ''), pair[1]]}
    .collect {|pair| pair.join(": ") << "<br>"}
    .sort
  [200, {'Content-Type' => 'text/html'}, headers]

pglombardo

Rails 4 is out featuring Russian Doll caching (AKA Cache Digests). In this article, I apply Russian Doll caching to one of my poorer performing Rails 3 pages using the cache_digests gem.

ActionView templates are great. They are easy to code, manage and extend but the one thing they are not is fast...at least not out of the box.

In this article, I'll be using AppNeta's TraceView to time ActionView performance. If you haven't used TraceView before, checkout my previous article Instrumenting Ruby on Rails with TraceView.

ActionView is Slow; Pitfalls Ahead

ActionView puts forth a great development pattern of views and partials that is easy to understand, implement and maintain but that comes at a cost: The rendering process is complex and slow.

pglombardo

#!/usr/bin/env ruby

require 'rubygems'
require 'instrumental_agent'
require "net/https"
require "uri"
require 'json'
require 'debugger'

INSTRUMENTAL_API_KEY='<insert_your_key>'

pglombardo

We're happy to say that we recently released the code for the TraceView Ruby instrumentation on Github as Open Source. There are a ton of benefits for AppNeta (and the community) in doing this so making the decision was easy... but the process of actually opening the repository and still keeping a few things private was slightly trickier. Here's the route we took that has worked out really well.

The Situation and Strategy

The Ruby instrumentation has always been sheltered on Github - albeit always in a private Github repository. We used the issues, pull requests and wiki pages extensively for everything from new employee resources to hosting screenshots, customer issues, internal discussions and links to other project and management tools (e.g. Asana).

Outside of the commits and the code, everything else was either of little use to the public or potentially company or customer confidential - stuff that shouldn't or couldn't be shared publicly. So this put us