a perfect website launch every time
DESCRIPTION
Here we breakdown how to have a perfect website launch every time that we unveiled at Drupal BADCamp 2013. Launches are tough on a new developer. Everyone remembers the lump in their throats around launch time; the rush to finish content, make final theme tweaks, adjust for sudden browser weirdness. As momentum picks up, the odd change request always appears, databases are slingshot hither and yon, while everyone scrambles to resolve merge conflicts like a Tokyo train at rush hour. We emerge scarred but smarter, intent on making the next launch less painful. But with different teams launching different sites, it can be hard to establish an iterative process. Especially as new work accumulates in the backlog, we reap what we sow in technical debt from rushed launches, quick & dirty choices made under the gun, and unimplemented ideas from retrospectives. Pantheon, however, has the same Customer Success team launching several Drupal enterprise websites per week, while assisting hundreds of self serve customers when they need a hand. Because we need to work effectively, we have developed the tools and process to ensure: - Great Site Performance - On Day One - Less problems over the long run - Clear Expectations from Informed Stakeholders These slides will cover other key areas: 1. Preparing For Launch for the PM, Stakeholder, Developer & Sys Admin 2. Auditing the Site for landmines, carnivorous acid pool islands, and deadweight 3. Load Testing to obliterate surprises with actionable results These slides are Platform Agnostic; whether you use PAAS, shared hosting, or wield your own hardware, PMs, developers, and clients will leave with new tools in their belt to launch. We will share some of our challenges and how we overcame them, and hopefully hear from you about how you overcame yours!TRANSCRIPT
A Prefect Lunch, Evry Tim BADCramp 2013
A Perfect Launch, Every Time BADCamp 2013
Introductions
• Suzanne Aldrich
• Jon Peck
• Timani Tunduwani
Why Cake?
• CAXE
• Clarity
• Accuracy
• eXecution
• Empathy
Challenges for a perfect launch
• On time
• On budget
• On plan
Encourage self-sufficient users
• Reduce cost
• Make it easier to work and learn
• Maintain good communication
Onboarding: Converting Newbies to Pros
Suzanne
How we prepare for launch
• Aim: Get rid of all the “Oh my God!” moments
• Recipe: Set clients up for success
• Stakeholders:
• Project Manager - best practices
• Business owner - flawless launch
• Developer - knowledge of platform
• Sys Admin - delegation
Have a system and tools
• Specify workflow requirements
• Task list system - do.com, Trello, OmniPlan
• Orientation logistics - gCal
• Email templates & forms - wiki, Google
• Online calls & screenshares - GoToMeeting
• Slideshows & scripts - Keynote
Mapping the territory
• Scoping of responsibilities
• Managing expectations
• Channels of communication
• Emergency procedures
• Primary inbox
• Communicating blockers
Site Auditing: Landmines, acid pools, and dead weight.
Jon
Why audit sites?
• Ensure optimal configuration
• Every site is unique, but…
• Built with the same framework
• Similar architectural requirements
• One size fits most.
What is static program analysis?
• Performance & behavior gathering
• Does not execute
• Non-intrusive
• Automated
Why use static program analysis?
• Fast
• Repeatable
• Detects common problems
What is Site Audit?
• Drupal 7 static analysis
• https://drupal.org/project/site_audit
• Best practices
• Actionable report
• formats: drush, HTML, JSON
What can Site Audit analyze?
• Drupal caching settings
• Codebase and file size
• Database structure
• Modules, including duplicate / missing
• Non-standard code structures
• Views caching
• Watchdog logs
What does static analysis not address?
• DOM / front-end performance
• Usability and site experience
• Aesthetics
• Content
[demo]
Load Testing: Obliterate surprises with actionable results
Timani
What does a load test measure?
• Performance
• Smoke
• Spike
• Stress
• Capacity
Why load test?
• Resource planning
• A/B testing
• Budgeting
When should I test?
• Before you write your first line of code!
• Xdebug, Webgrind, Devel, Syslog, Watchdog, New Relic
• Incrementally during development
• Prior to launch
Caching
• Opcode Cache
• APC, Zend Opcache, eAccelerator
• Backends
• Memcached, Redis, MongoDB, file system, APC
• Front-end caching
• Varnish, Squid, reverse-proxy CDNs
Testing Varnish With Curl
curl -‐Ik http://example.org
X-‐Varnish: 1844141790 1843977932
cache-‐control: public, max-‐age=900
expires: Sun, 19 Nov 1978 05:00:00 GMT
x-‐drupal-‐cache: HIT
x-‐generator: Drupal 7 (http://drupal.org)
Via: 1.1 varnish
Age: 697
What to expect during and after
• Benchmark often (datapoints vs aggregate)
• Be reasonable
• Numbers should dictate expectations (back-end not just Google analytics)
PHP Slow Log
[26-‐Sep-‐2012 23:41:50] [pool www] pid 17761 script_filename = /.../index.php[0x0000000001006408] execute() /.../includes/database/database.inc:2139 [0x0000000001005cf0] execute() /.../includes/database/database.inc:664 [0x0000000001005a38] query() /.../includes/database/select.inc:1264 [0x0000000001004760] execute() /.../sites/all/modules/views/plugins/views_plugin_query_default.inc:1398[0x0000000001003c40] execute() /.../sites/all/modules/views/includes/view.inc:1098[0x00000000010027f8] execute() /.../sites/all/modules/views/includes/view.inc:1118
Nginx error log
013/10/21 17:14:07 [alert] 23647#0: *53768 128 worker_connections are not enough while connecting to upstream, client: 127.0.0.1, server: , request: “POST /index.php?q=submit HTTP/1.0”, upstream: “fastcgi://unix:/srv/bindings/.../run/php-‐fpm.sock:”, host: “www.example.org”
MySQL slow log
# Time: 130320 7:30:26
# User@Host: db_user[db_database] @ localhost []
# Query_time: 4.545309 Lock_time: 0.000069 Rows_sent: 219 Rows_examined: 254
SET timestamp=1363779026;
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';
The bite is worse than the bark!
• Pay attention to your watchdog
• 6662 11/Oct 21:41 warning cron Attempting to re-‐run cron while it is already running.6652 11/Oct 15:05 warning php Warning: Cannot modify header information -‐ headers already sent by (output started at /srv/www/code/includes/common.inc:2700) in drupal_goto() (line6643 11/Oct 14:21 notice php Notice: Trying to get property of non-‐object in cap_ui_preprocess_page() (line 27 of /srv/www/code/sites/all/themes/cap_ui/template.php).6595 11/Oct 13:00 notice php Notice: Unknown: Can not authenticate to IMAP server: [AUTHENTICATIONFAILED] Invalid credentials (Failure) (errflg=2) in main() (line of ).6594 11/Oct 13:00 notice php Notice: Unknown: Retrying PLAIN authentication after [AUTHENTICATIONFAILED] Invalid credentials (Failure) (errflg=1) in main() (line of ). 6593 11/Oct 13:00 notice php Notice: Unknown: Retrying PLAIN authentication after [AUTHENTICATIONFAILED] Invalid credentials (Failure) (errflg=1) in main() (line of ).
New Relic
Who should execute the test
• Developers execute
• Involve stakeholders
Where to perform the test
• environment
• bandwidth
• resource limitations
• SAAS
Tools for load testing
• DIY and simple
• Apache Bench
• Complex / dynamic
• Apache JMeter
• Load Impact
• Load Storm
Interpreting results
• Hard numbers
• Business impact
Load Test report
What’s next?
• Own the results.
Thank you! !
Questions?