Play by Play - Planning and dealing with load

Based on the experiences from two of the biggest Magento projects we have delivered to date we will explore how to plan and deliver a Magento site that can support even the biggest traffic requirements.

What do you need to know about your users before you begin planning. How can you make accurate predictions about how your site will perform. Where are your efforts best invested to ensure that your site stays up and that your users spend money. What technology can we use to increase site performance and capacity. What services can help us support peaks in traffic and how do we know it is working.

What lessons have we learned and how did our plans perform over the duration of a business critical promotion period.

Transcript

1. PLAY BY PLAY Planning for and dealing with high traffic volumes on your Magento store
2. WHO AM I • Alistair Stead ~ @alistairstead • Technical Assurance Manager @ Ibuildings UK / Session Digital • Lead Magento projects for: • Dreams • Warner Music International • Kookai
3. REAL SCENARIO • Your client has a sale every year on the same day. • They have a loyal customer base who know about the sale. • They have sent over 5 million email advertising large savings. • The sale prices and products must all go live at 08:00 on sale day
4. Thats a lot of people waiting at the door!
5. WHAT ARE THE EFFECTS OF HIGH TRAFFIC VOLUMES • Initial site slowdown as requests are queued. • Eventual failure to respond to requests. • Inaccessible servers for any service • No effect just business as usual.
6. WHERE SHOULD WE FOCUS OUR ATTENTIONS • Optimising code factors such as DB queries or poorly thought out logic. • Reduce the page weight by optimising or removing elements. • Reduce the number of HTTP requests.
7. BOTTLENECK
8. HOW DO WE FIND BOTTLENECKS IN THE CODE • Cache Grind (WebGrind, CallGrind) http://bit.ly/Hwfl42 • XHPROF http://bit.ly/HweQXM
9. THEN WE NEED TO START TO EXPAND THE TECHNOLOGY • Lightweight faster servers (Apache, Nginx, Lighttpd) • Gateway caches (Varnish, Squid, Hardware cahing) •
10. OFF LOAD REQUEST TO OTHER SERVICES • CDN (Content Delivery Network) • Split the load using sub-domains to other servers
11. MONITORING UNDER HIGH LOAD • Munin • Cacti • Nagios • Many monitors and top
12. Simple solution
13. HOW TO ESTIMATE TRAFFIC AND CAPACITY • Acceptable response time. • Number of requests. • Number of concurrent requests.
14. C = (N*L) * (R / T) * D • C = Number of concurrent connections to handle based on the estimated traffic volume. • N = Total number of unique users. • L = Average user journey length in requests. • T = Total time in which the traffic will visit the site. • R = Average time of one request to be served by the system. • D = Deviation in traffic pattern.
15. EXAMPLE CONCURRENCY 266 = (40,000 * 10) * (2 / 3600) * 1.2
16. PROFILING UNDER LOAD • Jmeter • Siege • Apache Bench
17. PROFILING OUTPUT
18. EXAMPLE TOPOLOGY Web DB Master DB Slave DB Slave Web Web Web Web Web Web Web
19. LESSONS LEARNER Planning for your next big promotion
20. HOW TO DEAL WITH THE UNEXPECTED • Have a plan for even the most unexpected events. • Even if you have agreed not to change content plan a solution. • Consider temporarily revoking the clients access to the admin. • Delay import, export and indexing until later.
21. PLAN FOR CACHE EXPIRATION • The default magento cache will expire approx. every 6 hours • If this happens during a traffic peak your CPU will melt. • Temporarily set a far future cache expiration date.
22. Trouble is on the way!
23. CACHE STORM • Don’t assume this will not happen, it will! • Have a plan of how to deal with it. • Better yet create an architecture that can support the traffic with a completely cold cache.
24. NETWORK SATURATION • Under normal events your very unlikely to consider this. • Adding many more servers can start to expose network limitations. • Read the fine print from your hosting company. • Do not assume the capacity of switches confirm it!
25. ALTERNATE CACHE BACKEND • Zend_Cache_Backend_BlackHole • Zend_Cache_Backend_Redis
26. NO CACHE BACKEND <cache> <backend><![CDATA[memcached]]></backend> <slow_backend><![CDATA[Zend_Cache_Backend_BlackHole]]></slow_backend> <slow_backend_store_data><![CDATA[0]]></slow_backend_store_data> <auto_refresh_fast_cache><![CDATA[0]]></auto_refresh_fast_cache> /... </cache>
27. NO CACHE BACKEND <cache> <backend><![CDATA[memcached]]></backend> <slow_backend><![CDATA[Zend_Cache_Backend_BlackHole]]></slow_backend> <slow_backend_store_data><![CDATA[0]]></slow_backend_store_data> <auto_refresh_fast_cache><![CDATA[0]]></auto_refresh_fast_cache> /... </cache>
28. REDIS CACHE <cache> <backend><![CDATA[Zend_Cache_Backend_Redis]]></backend> <auto_refresh_fast_cache><![CDATA[0]]></auto_refresh_fast_cache> /... </cache>
29. REDIS CACHE <cache> <backend><![CDATA[Zend_Cache_Backend_Redis]]></backend> <auto_refresh_fast_cache><![CDATA[0]]></auto_refresh_fast_cache> /... </cache>
30. LOG TO AN ALTERNATE INTERFACE • Logging in Magento is key to some admin functions. • But this results in many DB queries per page request. • Exception logging is file based and not suitable to be shared over NFS • global/log/core/writer_model Specify a more appropriate log writter
31. SCALING PROBLEMS • Merged JavaScript and CSS • Image cache and generation
32. ARCHITECTURAL CHANGES • SOA (Service Orientated Architecture) • HMVC (Hierarchical MVC) http://bit.ly/HwpqOj
33. Don’t wait for any of these issues on promotion day!
34. THANK YOU! • Email: astead@ibuildings.com • Skype: astead-ibuildings • Twitter: @alistairstead
35. QUESTIONS?
36. WE ARE HIRING! http://www.ibuildings.co.uk/about/careers/