Running Production Apps on Heroku 6.27.13


Published on

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 - 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 -

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • We would also love to hear back from you as far as what other topics you’d like to hear about.
  • What do you see your customers use for monitoring
  • -You absolutely need the ability to handle requests concurrently. The reason why is slow running requests will block up your dynos and almost certainly lead to over provisioning and unnecessary queuing. -If using a single threaded language like ruby or python, a concurrent webserver is recommended. Specifically Unicorn or gUnicorn. -This will add a layer of intelligent routing into the dynos - The tradeoff here is that you’ll be increasing the memory footprint inside each application exponentially and you’ll need to do some tuning to make sure you don’t exceed the 512 default and get the most bang for your buck. - You can tune using a number of resources - log2viz and log-runtime-metrics. Find the footprint of one app and multiply while still staying under the cap
  • Running Production Apps on Heroku 6.27.13

    1. 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. 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. 3. IntroductionsIntroductions Jason Lee Customer Advocate @jglee081 Greg Nokes Technical Account Manager @tsykoduk
    4. 4. AgendaAgenda  Production App Necessities – 30 min  Log-runtime-metrics Demo – 10 min  Q&A – 10 min
    5. 5. What is a Production App?What is a Production App?  Out of Development  Emphasizes uptime  Response time is important
    6. 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. 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. 8. MonitoringMonitoring  Very important for trouble shooting, scaling, and maximizing uptime  Three recommended types of monitoring  Performance  Logging  Exception Tracking
    9. 9. SecuritySecurity  SSL(Secure Socket Layer) 
    10. 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. 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. 12. Visibility ToolsVisibility Tools  Two Great resources.  Log2viz –  Log-runtime-metrics -
    13. 13. 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
    14. 14. 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
    15. 15. ResourcesResources  Log2viz:  Log-runtime-metrics:  Getting started with unicorn:  Follower database: databases  Which postgres plan is right for you? postgres-plans  Production Check:  Building apps efficiently blog post:  Bloat Script used in demo:
    16. 16. Q&AQ&A Jason Lee Customer Advocate Greg Nokes Technical Account Manager