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