This deck is from a live presentation on 6/27/13 which featured an in-depth look at how to setup and run production apps on Heroku. This is the first session of a two part series on production apps on Heroku and is meant for an audience familiare with Heroku basics. Video recording can be found here - http://vimeo.com/69263217. The second more advanced session will be covered in July 2013. Topics for this presentation include: * Production app setup and expectations * App production checklist * Using Unicorn to increase app performance * Using 2X dynos to increase app performance * How to configure timeouts to ensure app stability * Using log-runtime-metrics for added visibility Looking for 1:1 assistance with your production apps, please contact our Customer Success team here - http://lp.heroku.com/ProductionApps.html?mkt_tok=3RkMMJWWfF9wsRow5%2FmYJoDpwmWGd5mht7VzDtPj1OY6hBkvKrWJK1TtuMFUGpsqOOGbEw0bBg%3D%3D

1. Running Production Apps on HerokuRunning Production Apps on Heroku
Jason Lee, Customer AdvocateJason Lee, Customer Advocate
@jglee081@jglee081
Greg Nokes, Technical Account ManagerGreg Nokes, Technical Account Manager
@tsykoduk@tsykoduk

2. Purpose, Expectations and AssumptionsPurpose, Expectations and Assumptions
This is the first of a two part series on running production applications. We
want you to be armed with the tools and knowledge to get the most out of
Heroku.
-Today we will be covering more basic concepts and making sure the
foundation of your critical app is set.
-Our next webinar will take a deeper dive.
-We assume that you have cursory Heroku knowledge and are familiar with
our terminology and command line.

3. IntroductionsIntroductions
Jason Lee
Customer Advocate
@jglee081
Greg Nokes
Technical Account Manager
@tsykoduk

4. AgendaAgenda
 Production App Necessities – 30 min
 Log-runtime-metrics Demo – 10 min
 Q&A – 10 min

5. What is a Production App?What is a Production App?
 Out of Development
 Emphasizes uptime
 Response time is important

6. Production App NecessitiesProduction App Necessities
• Concurrency at the dyno level
• Monitoring
• Security
• Concurrency within a dyno
• Appropriate dyno size
• Database Size and Failover

7. Concurrency at the Dyno levelConcurrency at the Dyno level
 With 1 dyno your application will idle, at 2+ we remove idling.
 With two or more dynos we can handle server health issues by
restarting dynos and re-deploying your code. Traffic will be load
balanced and sent to healthy dynos.
 Heroku will re-deploy your application, this happens invisibly to
you

8. MonitoringMonitoring
 Very important for trouble shooting, scaling, and maximizing
uptime
 Three recommended types of monitoring
 Performance
 Logging
 Exception Tracking

9. SecuritySecurity
 SSL(Secure Socket Layer)
 https://devcenter.heroku.com/articles/ssl-endpoint

10. Concurrency within a dynoConcurrency within a dyno
 Why is this important?
 Web dynos have a built in 30 second timeout, which generates an
H12 error.
 It’s important to keep queuing to a minimum. A single threaded dyno
can become blocked up with long running requests.
 We recommend requests that average ½ second or more be moved
to a worker dyno.
 Solution is a concurrent Webserver. Unicorn for Ruby, gunicorn
for Python

11. Tuning UnicornTuning Unicorn
 Trade off of Unicorn is in the memory consumption
 By default we recommend 3 workers. For best results you’ll
want to tune your app for the maximum number of unicorn
workers while still staying safely below the 512mb cap
 Configuring Timeouts
 Unicorn Timeout, this will kill your process.
 Rack Timeout gem will kill off long running requests in
your dyno

12. Visibility ToolsVisibility Tools
 Two Great resources.
 Log2viz –
 Log-runtime-metrics -

14. Appropriate Dyno SizeAppropriate Dyno Size
 You’ll want at least 3 unicorn workers per dyno.
 At a certain size you may want more RAM and CPU shares. At
that point upgrading to 2x dynos becomes an option.
 At scale it’s better to have 2x dynos and reduce the overall
dyno count

15. Database Size and FailoverDatabase Size and Failover
 You must be on a Production DB plan(Crane or higher)
 More Robust, better supported, provides uptimes tools, allocated cache
memory, ability to create followers
 Determine the size of your DB by doing cache hit checks.
 You’ll want that ratio to be 99% or better.
 Use pg_extras to find those numbers
 Follower Databases
 We back everything up with postgres writeaheadlogs
 This provides instant failover
 Provides performance boost by splitting reads

17. ResourcesResources
 Log2viz: https://blog.heroku.com/archives/2013/3/19/log2viz
 Log-runtime-metrics: https://devcenter.heroku.com/articles/log-runtime-metrics
 Getting started with unicorn: https://devcenter.heroku.com/articles/rails-unicorn
 Follower database: https://devcenter.heroku.com/articles/heroku-postgres-follower-
databases
 Which postgres plan is right for you? https://devcenter.heroku.com/articles/heroku-
postgres-plans
 Production Check: https://devcenter.heroku.com/articles/production-check
 Building apps efficiently blog post:
https://blog.heroku.com/archives/2013/6/12/building_apps_efficiently_on_heroku
 Bloat Script used in demo: https://github.com/tsykoduk/hello_world

18. Q&AQ&A
Jason Lee
Customer Advocate
Greg Nokes
Technical Account Manager