magento performances 2015 best practices

Bargento 2015

Magento performancesBest practices 2015

LEADER en INFOGERANCE ECOMMERCE EXPERT en TRES HAUTE SECURITE

Grow your business safely

WWW.NBS-SYSTEM.COM

7 years of experience


Realities and the myths

• Myth: SSD disks are a major key to performances• Myth: HHVM could save us• Myth: Varnish will save us• Reality: PHP is the bottleneck• Reality: MySQL is overly queried by Magento• Reality: separation is a key• Reality: added code is often the root cause of

problems

3Présenté par Philippe Humeau

Most common problems

• Misconfigured cache systems• Not leveraging the Reverse Proxies’ help• Crowded .htaccess files (& lots of them)• Crowded databases• Terrible SQL queries• Wrong design (load all products on the

homepage)


PHP


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


PHP versions in use in our

parc

PHP 5.23%

PHP 5.351%

PHP 5.437%

PHP 5.59%

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

PHP performances progresses


PHP 5.3 (deprecated) → PHP 5.6 +39,6%

PHP 5.4 (end of life) → PHP 5.6 +12,7%PHP 5.5 → PHP 5.6 +3,5%PHP FPM instead of Mod PHP +18,6%Nginc + PHP FPM vs Apache PHP FPM Margina

lPHP 7 or HHVM vs PHP 5.6 *experimental* +200%

PHP: benefits of a 3 tiers architecture with FPM


• Better layers and function separation (view, logic, data)

• Better stability through process independency

• More efficient resources consumption• Easier troubleshooting• Capacity to boost specific tiers depending

on the need

MySQL


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


• Magento can use different database servers• Based on accessed tables• It is easier to specialize/customize their

settings• It avoids delaying one request, blocked by

another• Allows for more granularity (catalog, orders,

logs, etc.)• Can separate reads & writes (hence locks)

Database: some key settings


• « Defaults » settings are not available since they depend on the DB content

• Cache query is nearly mostly inefficient (& always > 1000 queries/sec)– innodb_thread_concurrency– table_open_cache (should be big enough to store modules tables)– innodb_read_io_threads– innodb_write_io_threads– innodb_buffer_pool_size (big enough to store both data & indexes)– max_heap_table_size– tmp_table_size

Clean the database often & defragment them


Can I do it with my Magento?


Versions & compatibility


Caches


Black cache – PHP validates & assembles


FCP very few PHP calls


Custom blocks: performance killers


When caches are inefficient

Example of a wrongly configured fast/slow cache duel


When caches are inefficient

Example of a cache limit at 80% filling reachedCareful, 1.14.0 has compatibility issues with Redis 2.6.xMemcached prior to 1.4.20 has a 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 keeps Varnish from being 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 needs to « punch

holes »– Those holes are filled by the dynamic information coming from

the server (server side included)– The other parts of the page are FPCed (no PHP calls)– Magento’s extension, « Turpenting » 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

Code


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’s 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 are no better


• Sleek design is the key– Don’t overcrowd the pages with useless features– Don’t load too many categories / products on the 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 soon as the homepage– Avoid CSS/HTML/JS errors– Load images at the display size (not 3Mo for 300ko

displayed)– Avoid having too many (Magento) blocks on pages– Avoid all information deactivating Varnish or FPC

Architecture


One server, one role


• Caches– Redis instances MUST be separated– Even Redis databases should be separated (especially for multi

stores)– Redis doesn’t support latency– So the cohabitation with DB, PHP or Apache/Nginx is bad

• PHP– Separated processes (FPM) are better– Separation of BO / FO / order tunnels with SSL allows for 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

datacenters– Even a 2 ms latency makes a difference in the database

output• Redis

– It’s even worse for Redis

Amazon


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 allows autoscalling, auto backup, auto update,

replication in multi AZ– ELC allows to use Memcached / Redis in multi zone & fail

over– Leveraging ELB, R53, Cloud front and S3 allows a shop to

be nicely distributed

AWS: adjustments needed


• No NFS or shared filesystem as such– Use 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 usually local to the server– The 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 than 1/1000 of Magento stores are running (and can

run) on AWS

Processing & DevOps are the key to success

Fine tuning


• Caches– Aoe_AsyncCache– Aoe_CacheCleaner– Aoe_static (make page cachable by Varnish)

• Magento– Disable logs on high throughput instances– Separate heavy duty tables in different RDS instances

http://bit.ly/1FWjn5p : Angry birds in the Cloudhttp://bit.ly/1N3fuev : high performance Magento on Amazonhttp://bit.ly/1R2jPiI : Basic tips & tricks about Magento per

AWS: a different architecture


Code publishing


Code publishing automation


• Using Git|Jenkins|Chef|Subversion|Capistrano|Turtoise– Allows to keep track of versioning– Allows to roll back when the site go AWOL– Allows to use post process scripts & report

• Automating the code publishing– The 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 the

orders registered between the new and old site database

Contact

NBS SystemAdresse : 8 rue Bernard Buffet, Immeuble Le Cardinet – 5ème étage75017 Paris

Mail : [email protected]éléphone : +33.1.58.56.60.80Support technique : +33.1.58.56.60.88Fax : +33.1.58.56.60.81

39

Atelier présenté le 13 octobre 2015 au Bargento 2015 par Philippe Humeau

Présenté par Philippe Humeau

magento performances 2015 best practices

Technology