This slide deck covers some of our Magento performances and optimisation best practices as we know them. We (NBS System) host 1800+ Magento shops since 2008, we hope this will help a lot of you to get good performances and enhance your conversion rate. It's not 100% complete coverage since it was a slide deck made for a 1H conference, but if you need more insights, contact us. Happy e-Commerce everyone!
21. 21www.nbs-system.com 21www.nbs-system.com
When caches are inefficient
Example of a cache limit at 80% filling reached
Careful, 1.14.0 has compatibility issues with Redis 2.6.x
Memcached prior to 1.4.20 has bug triggered under heavy load
22. 22www.nbs-system.com 22www.nbs-system.com
Key local.xml settings
Caches
<slow_backend_store_data>0</slow_backend_store_data>
<auto_refresh_fast_cache>0</auto_refresh_fast_cache>
<compress_data>0</compress_data>
<compress_tags>0</compress_tags>
<lifetimelimit>86400</lifetimelimit>
Sessions
<timeout>3</timeout> <!-- 2.5 can lead to problems -->
<max_concurrency>10</max_concurrency>
23. 23www.nbs-system.com 23www.nbs-system.com
Varnish: Amplifying the good, not hiding the worse
The problem
• Magento sends the frontend cookie with every request
• This prevent Varnish to be efficient
Keeping SSL under control
• SSL pages are not cachable by Varnish (with Apache)
• Delay the use of SSL to Tunnel & BO (non cachable anyway)
Use ESI best practices
• To properly leverage Varnish FPC, one need to “punch holes”
• Those holes are filled by the dynamic information coming
from the server (Server side include)
• The other parts of the page are FPCed (no PHP calls)
• Magento Trupentine extension does this
24. 24www.nbs-system.com 24www.nbs-system.com
Use Quanta computing
In depth Magento troubleshooting
• Allow to identify bottlenecks
• Allow to measure a per user resource consumption
• Tracks blocks generation timings
Tracking performances overtime
• Can monitor cache flush
• Can relate new code in production with performance variation
26. 26www.nbs-system.com 26www.nbs-system.com
Bad added code is the main pain point
Community extensions
• Most plugins are not tested by Magento
• Most are utterly wrongly done or unoptimized
• Loading too many of them burdens the whole Magento
Home made custom code & extensions
• Your blocks are unknown from Magento cache system
• Be careful about the endless « Natural Join » queries
• Test / monitor your site before and after new code is added
• Never, ever touch the CORE (or we kill a kitten)
27. 27www.nbs-system.com 27www.nbs-system.com
Bad templates, not better
Sleek design is the key
• Don’t overcrowd the pages with useless features
• Don’t load too many categories / products on homepage
• Avoid including lots of gadgets like facebook
• Avoid including too many external services/JS
• Try to Ajaxify things
• K.I.S.S : Keep It Super Simple
• Don’t load tons of extensions as of the homepage
• Avoid CSS/HTML/JS errors
• Load images at the display size (not 3 Mo for 300 ko displayed)
• Avoid having too many (Magento) blocks on pages
• Avoid all informations deactivating Varnish or FPC
29. 29www.nbs-system.com 29www.nbs-system.com
One server, one role
Caches
• Redis instance MUST be separated
• Even Redis databases should be separated (especially for multi stores)
• Redis doesn’t support latency
• Hence cohabitation with DB, PHP or Apache/Nginx is bad
PHP
• Separated process (FPM) are better
• Separation of BO / FO / Order tunnels with SSL allows better performances
• No need to handcuff them with the Web server
Database
• Separate reads from writes
• Isolate highly demanded tables in another instance
30. 30www.nbs-system.com 30www.nbs-system.com
Warnings on latency issues
Database
• Machines, to be redundant, have to be in separated Datacenter
• Even 2 ms latency makes a difference in database output
Redis
• It’s even worse for Redis
32. 32www.nbs-system.com 32www.nbs-system.com
AWS: Use native tools
Taking advantage of the *real* AWS killer feature
• A Magento can be done the same way on amazon, but you would miss
90% of the benefits of AWS
• Leveraging RDS (postgres, oracle, mssql, mysql, aurora) is key
• RDS allow autoscalling, auto backup, auto update, replication in multi AZ
• ELC allow to use Memcached / Redis in multi zone & fail over
• Leveraging ELB, R53, Cloud front and S3 allow a shop be nicely distributed
33. 33www.nbs-system.com 33www.nbs-system.com
AWS: adjustments needed
No NFS or shared filesystem as such
• Use the an extension to distribute media to S3 buckets
• The medias cannot be modified only on one machine
• The deployment systems must be adapted
• File locks can be tricky to handle
• Generated reports are local to server usually
• Backoffice is handled differently (and isolated)
• Thumbnails are per servers, meaning a different way to share
34. 34www.nbs-system.com 34www.nbs-system.com
Auto Scaling Group: doable, but technical
Auto scaling groups
• Fantastic on paper but not natively supported in Magento
• Can be achieved in several ways
• EBS can be counter productive, ephemeral FS can be better
• Since the extensible machines are mounted & dismounted on
the fly, scripts will have to post process the installation
• Doable but need a perfectly “dry” setup
• Threshold can be tricky to configure
• Less 1/1000 Magento store are (and can) running on AWS
Processing & Devops are the key to success
35. 35www.nbs-system.com 35www.nbs-system.com
Caches
• Aoe_AsyncCache
• Aoe_CacheCleaner
• Aoe_static (make page cachable by varnish)
Magento
• Disable logs on high throughput instances
• Separated heavy duty tables in different RDS instances
Fine tuning
http://bit.ly/1FWjn5p : Angry birds in the Cloud
http://bit.ly/1N3fuev : high performance Magento on Amazon
http://bit.ly/1R2jPiI : Basic tips & tricks about Magento perf
38. 38www.nbs-system.com 38www.nbs-system.com
Code publishing automation
Using Git|Jenkins|Chef|Subversion|Capistrano|Turtoise
• Allow to keep track of versioning
• Allow to roll back when the site go AWOL
• Allow to use post process scripts & report
Automating the code publishing
• Main difference is usually the local.xml file
• And some databases settings potentially
• Scripts can (& should) do the job
• Rollback should be thought carefully because of orders
registered between the new and old site database