Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Play by Play - Planning and dealing with load

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.

7ad4c8a7218e44fdf1600b4ebc451738?s=128

Alistair Stead

March 31, 2012
Tweet

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/