magento performances best practices 2015 - nbs system€¦ · 11 magento performances best...

1www.nbs-system.com

1

Magento performances

Best practices 2015

Q4 2015

Grow your business safely

2www.nbs-system.com

2

7 years of experience

www.nbs-system.com

3www.nbs-system.com

3www.nbs-system.com

Realities and the myths

4www.nbs-system.com

4www.nbs-system.com

Most common problems

5www.nbs-system.com

5

PHP

www.nbs-system.com

6www.nbs-system.com

6www.nbs-system.com

PHP: FPM can help but, first, version matters a lot

PHP versions

in use in our

parc

7www.nbs-system.com

7www.nbs-system.com

PHP: FPM can help, but version matters most

PHP performances progresses

PHP 5.3 (deprecated) –> PHP 5.6

PHP 5.4 (end of life) –> PHP 5.6

PHP 5.5 –> PHP 5.6

+39,6%

+12,7%

+3,5%

PHP FPM instead of Mod PHP +18,6%

Nginx + PHP FPM vs Apache PHP FPM Marginal

PHP7 or HHVM vs PHP 5.6 *experimental* +200%

8www.nbs-system.com

8www.nbs-system.com

PHP: Benefits of a 3 tiers architecture with FPM

9www.nbs-system.com

9

MySQL

www.nbs-system.com

10www.nbs-system.com


MySQL: Percona, a transparent booster

Not a single change needed, just pure bonus.

MySQL 5.5–> MySQL 5.6 +17%

MySQL + Percona +20%

MySQL + Percona + XtraDB Not meaningful



Database: Separate your key tables



Databases: Some key settings



Clean the database, often & defragment them


14

Can I do it with my Magento?

www.nbs-system.com



Versions & compatibility


16

Caches

www.nbs-system.com

17www.nbs-system.comwww.nbs-system.com

Block cache PHP validates & assembles

17


FPC very few PHP calls

18


Custom blocks: perf killers

19



When caches are inefficient

•pb des version 1.14 EE avec Redis•Bug Memcached <1.4.23

Example of a wrongly configure fast/slow cache duet



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

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> <max_concurrency>10</max_concurrency>



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



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


25

Code

www.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)



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


28

Architecture

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



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


31

Amazon

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



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



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



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



AWS: a different architecture


37

Code publishing

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


Contact

Grow your business safely

[email protected] +33.1.58.56.60.80

www.nbs-system.comTwitter : @nbs_system

www.nbs-system.com

magento performances best practices 2015 - nbs system€¦ · 11 magento performances best...

Documents