1.
NENÄPÄIVÄ
PERFORMANCE
BOOST
Janne Alho
Nenäpäivä PM
Project Director, Exove

2.
Nenäpäivä technical view
 Drupal site with
 Commerce Module
 Personalized teams – Team admin logins
 Custom module
 Donations
 External interfaces handling (other team collections status)
 Teams calculation
 Campaign site with different campaign phases
 Main event happens once a year
 Main use is anonymous browsing
 Main load is registered use cases (commerce and team
admins)

3.
Nenäpäivä campaign
phases 1-3/4
 Phase 1 – Site preparation, content updates
 Phase 2 – Pre-campaign




Free content uploading
Commerce material orders
Teams creation
No specific traffic peaks
 Phase 3 – Campaign period
 Main usage was anonymous site browsing
 Campaign information, donations targets, ideas how to help
 Team donations and updates
 “Real time” team € collection status
 3 minutes Drupal/Varnish cache
 Commerce orders
 Traffic peaks in anonymous browsing
 Specific team pages refresh – Varnish took majority of the peaks

4.
Nenäpäivä campaign
phases 4/4
 Phase 4 – Nenäpäivä evening
 8.11. 19:00 – 24:00
 Peak use
 50% of all yearly traffic in one evening
 Use cases:
 Donations
 Donations
 Donations
 Phase 4’ – Cleanup
 After main event evening return back to normal
configurations, prepare for next year

5.
TRAFFIC PRE-ANALYSIS
AND
PEAK PREPARATIONS

6.
Peak pre-analysis and
preparations 1/2
 Estimating main user activities
 Study of previous year traffic, review of implemented changes in
service and campaign feed-back
 Defining service priorities
 Donation capability
 Generic and Team donations
 Easy to use (multiple starting points, intuitive, everything works)
 Donations emotional support
 Who are the ones you are helping
 Stories, videos, data
 Teams promotions
 All other features (including commerce) clearly lower priority
-> Focus area clear, keep site up and donations working

7.
Peak pre-analysis and
preparations 2/2
 Keep donations running as priority – what it means
 Donation capability build with custom module (instead of as part of commerce)
 No registering
 Reduce Drupal load
 Possibilityto use Varnish
 Optimized interface towards payment system
 Optimized reporting
 HW boost plan
 Architecture does not allow site to be distributed (due to team donations data calculations)
 Main virtual server increased performance
 Memory 4GB –8GB
 CPU2 core -> 4 cores
 Separate Varnish to own virtual machine (4GB memory, 2 CPU cores)
 Disk space analysis (no need to increase, just basic log space cleanup)
 Contingency plan
 Shut down Commerce
 Disable T
eam admin login
 None needed

8.
Summary
 Key success factors
 Know your traffic
 Implement architecture to fit services and traffic
 Plan fox success
 Plan for disaster

9.
THANK YOU!
Questions?