This document provides guidance on how to properly launch a new website or application. It emphasizes the importance of thorough preparation, documentation of roles and responsibilities, effective communication practices, and testing to eliminate problems. This includes performing a site audit to identify issues, mapping processes, encouraging self-sufficiency, and load testing to ensure optimal performance and capacity under stress. The goal is to establish best practices and systems that result in flawless launches and set clients up for success.

1. A Prefect Lunch…
Evry Tim
#SANDcramp 2014

2. A Perfect Launch…
Every Time
#SANDcamp 2014

3. Challenges for a perfect launch
● On time
● On budget
● On Plan

4. Encourage self-sufficient users
● Reduce cost
● Easier to work and learn
● Maintain good communication

5. Onboarding
Converting Newbies to Pros

6. How we prepare for launch
● Aim: Get rid of all the “uh-oh” moments
● Recipe: Set clients up for success
● Stakeholders:
○
○
○
○
Project Manager - scheduling, best practices
Developer - platform knowledge, integration
Sys Admin - responsibilities, delegation
Business owner - flawless launch

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

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

10. Site Audit
Landmines, acid pools, and dead weight.

11. Why audit sites?
●
●
●
●
●
Ensure optimal configuration
Every site is unique, but…
Built with the same framework
Similar architectural requirements
One size fits most.

12. What is static program analysis?
●
●
●
●
Performance & behavior gathering
Does not execute
Non-intrusive
Automated

13. Why use static program analysis?
● Fast
● Repeatable
● Detects common problems

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

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

16. What does it not analyze?
●
●
●
●
DOM / front-end performance
Usability and site experience
Aesthetics
Content

17. Drush format

18. HTML format with optional Bootstrap

19. JSON format

20. Launch Check
● Site Audit in the Pantheon dashboard
○ Uses --vendor=pantheon config
● Most actionable checks
● Runs automatically

22. Best practices

23. Drupal caching settings

24. Drupal cron

25. Drupal’s database

26. Extensions (modules & themes)

27. Drupal’s System Status

28. Users

29. Views

30. Watchdog

31. Test Configuration
● 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

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

33. Good configuration matters.

34. Load Testing
Obliterate surprises with actionable results

35. What does a load test measure?
●
●
●
●
●
Performance
Smoke
Spike
Stress
Capacity

36. Why load test?
● Resource planning
● A/B testing
● Budgeting

37. When should I load test?
● Before you write your first line of code!
○ Xdebug, Webgrind, Devel, Syslog, Watchdog, New
Relic
● Incrementally during development
● Prior to launch

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

39. Testing Varnish with cURL

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

42. PHP Slow Log

43. Nginx error log

44. 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';

45. Pay attention to watchdog
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() (line
6643 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 ).

46. New Relic

47. Who should execute the test
● Developers execute
● Involve stakeholders

48. Where to perform the test
● Live environment
○ Bandwidth
● Resource limitations
● SaaS

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

50. Interpreting results
● Hard numbers
● Business impact

51. Load Test report

52. Own the results.

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