Launching websites is hard. In the rush of last-minute changes, something always breaks. How could you have known the caching settings were mis-configured? Or maybe it’s the database. Your team is working overtime, but it’s already too late. Don’t let your site be one of the 60% of Drupal sites that launch late. Take steps now to lock in a perfect launch, every time. The Pantheon Launch Team launches several enterprise sites everyday, and supports hundreds of self-serve customers daily. In this platform-agnostic session, you’ll learn best practices and tools for rooting out problems and doubling site performance by launch day (whether you use PaaS, shared hosting, or your own hardware). You’ll learn: How to lead an agile, coordinated launch with project managers, stakeholders, developers, sysadmins—without spending months herding cats What causes 80% of website slowdowns and other problems—and how to obliterate surprises Top tools for benchmarking your performance and capacity Why you need a cache strategy if you care about performance—and specific things to think about before you configure your settings When to automate the launch prep—and when to call on an expert pair of eyes

1. A Perfect Launch,
Every Time
DrupalCon Austin 2014

2. What is a perfect launch?
● Schedule - On Time
● Cost - On Budget
● Scope - On Plan

3. Why should you care?

4. A Perfect Launch Recipe
● Launch Team - Onboarding
● Launch Check - Best Practices
● Load Test - Performance Tuning

5. Launch Team
Onboarding

6. How we prepare for launch
● Goal: Get rid of all the “uh-oh” moments
● Method: Launch Team
● Stakeholders:
o Project Manager - scheduling, best practices
o Developer - platform knowledge, integration
o Sys Admin - responsibilities, delegation
o Business owner - flawless launch

7. Have a system and tools
● Specify common workflow requirements
o Repeatable tasks, delegatable
● Project management - Wrike, JIRA, Redmine
● Orientation logistics
o Scheduling - calendar, deadlines
o Real-time communication
 Phone, Video Conference, GoToMeeting, IRC
o Training - documentation, Slides, Videos

8. Mapping the terrain
● Scoping of responsibilities
o Reduce confusion, set stage
● Channels of communication
o Define emergency procedures
o Issue tracking as primary inbox
● Staying in touch
o Available, open, and regular
o Proactive

10. Launch Check
Best Practices

11. What is Site Audit?
● Drupal 7 static analysis
o https://drupal.org/project/site_audit
● Best practices
● Actionable report
● Vendor agnostic
o Optional Pantheon specific recommendations

12. What can an audit analyze?
● Drupal caching settings
● Codebase and file size
● Database structure
● Modules, including duplicate / missing
● Non-standard code structures
● Views caching
● Watchdog logs

14. Drupal caching settings

15. Drupal cron

16. Drupal’s database

17. Extensions (modules & themes)

18. Views

19. Watchdog

20. ● Simple Drupal 7 site
● Apache Bench
○ 10,000 requests to home page (5 concurrent)
● Warmed cache, cleared watchdog
● Comparison
○ Bad config, 1 PHP notice and warning in theme
○ Good config, no PHP notices or warnings
Test Configuration

21. Result? Doubled performance.
Bad config, errors
● 20 min, 52 sec
● Requests per second: 7.98
● Time per request: 626.192 ms
Good config, no errors
● 10 min, 25 sec
● Requests per second: 15.99
● Time per request: 312.780 ms

22. Good configuration matters.

23. Load Testing
Performance Tuning

24. Why load test?
● Validate response times under peak load
● Smoke - operations under normal load
● Stress - behavior past peak load
o Spike - short bursts
● Capacity - plan for growth

25. Who should execute load tests?
● Developers execute
● Involve stakeholders

26. Tools for load testing
● DIY and simple
o Apache Bench
● Complex / dynamic
o Apache JMeter
o Load Impact
o Load Storm

27. When should I load test?
● Baseline
● Tools
o Xdebug, Webgrind, Devel, Syslog, Watchdog, New Relic
● Incrementally during development
● Prior to launch

28. Where do I perform load tests?
● Live environment
o Bandwidth
● Resource limitations
● SaaS load testing solutions

29. What to expect during & after
● Benchmark often (datapoints vs aggregate)
● Be reasonable
● Numbers should dictate expectations (back-end not just Google analytics)

30. Caching
● Opcode Cache
o APC, Zend Opcache, eAccelerator
● Backends
o Memcached, Redis, MongoDB, file system, APC
● Front-end caching
o Varnish, Squid, reverse-proxy CDNs

31. Back-end caching
Redis: Engage!

32. Front-end caching
Anonymous page caching: Disabled!

33. Testing Varnish with cURL

35. PHP Slow Log

36. Nginx error log

37. MySQL slow log
# Tim e:130320 7:30:26
# User@ Host:db_user[db_database]@ localhost[]
# Q uery_tim e:4.545309 Lock_tim e:0.000069 Row s_sent:219 Row s_exam ined:254
SET tim estam p= 1363779026;
SELECT option_nam e,option_value FRO M w p_options
W HERE autoload = 'yes';

38. Pay attention to watchdog
6652 11/O ct15:05 w arning php W arning:Cannotm odify headerinform ation -headers already sentby (outputstarted
at/srv/w w w /code/includes/com m on.inc:2700)in drupal_goto()(line
6643 11/O ct14:21 notice php Notice:Trying to getproperty ofnon-objectin cap_ui_preprocess_page()(line 27 of
/srv/w w w /code/sites/all/them es/cap_ui/tem plate.php).
6595 11/O ct13:00 notice php Notice:Unknow n:Can notauthenticate to IM AP server:[AUTHENTICATIO NFAILED ]Invalid
credentials (Failure)(errflg= 2)in m ain()(line of).

39. Good load test

40. Bad load test

41. Interpreting results
● Hard numbers
● Business impact

42. A Perfect Launch, Every Time

43. @ getpantheon
irc.freenode.net# pantheon
getpantheon.com
Thank you! Questions?