Unicorn Learnings

and a lil’ Varnish

Tuesday, July 20, 2010

 Motivation

• Unicorn is not like Mongrel.

• Unexpected behavior largely stems from
lack of understanding.

Tuesday, July 20, 2010

 Terminology
• Restart

• Upgrade

• Start

• Signals

• PIDs

• ‘bad code’

• preload_app

• spawn loop

• master & worker

Tuesday, July 20, 2010

 What makes Unicorn
great.
• Manages workers. Will respawn dead children.

• Supports reloading of code without loss of traffic.

• Great performance.

• Rack server.

• Only one TCP port to manage per app. (Look ma’ no 128 port clusters!)

• Balancing between ‘workers’ is done by OS by built-in solid Unix process

management.

• ...

Tuesday, July 20, 2010

 preload_app
• Workers load app themselves or from master.

• Workers startup ALOT faster if preloaded.

• Can save memory.

• BUT Has side effects.

Tuesday, July 20, 2010

 Spawn Loop
• Master process repeatedly create workers
who die until code is fixed or master is
killed.
• /usr/sbin/lsof -i -P | grep LISTEN
| grep 8080

Tuesday, July 20, 2010

 Default Unicorn
scripts/use-cases

Tuesday, July 20, 2010

 Start
• No process at all, duh.
• Start Unicorn via unicorn_rails or unicorn
with -D.

Tuesday, July 20, 2010

 Start + Bad Code
• What happens with bad code?
• preload_app:false = spawn loop.
• preload_app:true = Unicorn dies and
unfortunately leaves a PID file.

Tuesday, July 20, 2010

 ‘Upgrade’
• USR2 sent first
• Look for the oldbin
• QUIT
• Also called binary replacement
• How does preload_app affect?

Tuesday, July 20, 2010

 ‘Restart’
• Not the same as restart for Mongrel.
• Send HUP
• Simply restarts workers.
• How does preload_app affect?
• What about bad code?

Tuesday, July 20, 2010

 Current Restart
• USR2
• Sleep 1 (what if it takes longer)
• Check for both PIDS
• QUIT
• If both PIDs not found, FAIL

Tuesday, July 20, 2010

 What happens if?

• USR2 issued and no QUIT?

• Bad code is deployed?

Tuesday, July 20, 2010

 Demostrate USR2

Tuesday, July 20, 2010

 preload_app
• Workers load app themselves or from master?
• Can affect performance in few ways.
• Has side effects.
• HUP + (preload_app : true) = new code
will not get picked up.

• Bad Code + preload_app : false = Spawn

loop!

Tuesday, July 20, 2010

 Good Unicorn

Tuesday, July 20, 2010

 Bad Unicorn

Tuesday, July 20, 2010

 Unicorn Conclusions
• Let’s learn from Github config. (http://
github.com/blog/517-unicorn )
• Use before_fork callback to check for old
master and kill off rather than in shell.
• preload_app is our friend but understand
what it does.
• More info on Wiki search for
‘Understanding Unicorn Processes’

Tuesday, July 20, 2010

 Varnish Tips

Tuesday, July 20, 2010

 Is Varnish in front of
app?

• Look for X-Varnish HTTP header.

Tuesday, July 20, 2010

 Is Page Cached?

• X-Varnish has 1 number = Not cached.

• X-Varnish has 2 numbers = cached.

Tuesday, July 20, 2010

 Purging
• If issues occur or deployment happens.
• telnet to Varnish admin console (port 6082)
• Issue ‘url.purge .*’ for everything
• Issue ‘url.purge ^\/onboard\/v1\/
neighborhoods\/popular.html.*’ to kill all
object for ‘/onboard/v1/neighborhoods/
popular.html’

Tuesday, July 20, 2010

 How to work with
sessions and cookies?
• Unless there is a Varnish rule to not cache a GET
request, don’t assume you can use cookies or
session.

• In most cases,Varnish strips ALL cookies/session

coming from backend AND coming in from client.

• Use a specific ‘localize’ route to get cookies/

dynamic data when needed.

• Use AJAX and Javascript to interact with Cookies.

Tuesday, July 20, 2010

 Example Localize call
def localize

targetcode = Service::JSON.get("onboard/v1/
targetcode.json?geocode=#{@local_latitude},#
{@local_longitude}")

render :json => {:state =>

@local_state, :city => @local_city, :zip =>
@local_zip, :msa => @local_msa, :latitude =>
@local_latitude, :longitude =>
@local_longitude, :targetcode =>
targetcode}.to_json

end

Tuesday, July 20, 2010

 The end

Tuesday, July 20, 2010