Performance, Scale

and Magento 2

Ted PietrzakHead of Magento Technology

Legal Disclaimer

Copyright © 2015 Magento, Inc. All Rights Reserved.

Magento®, eBay Enterprise™ and their respective logos are trademarks, service marks,

registered trademarks, or registered service marks of eBay, Inc. or its subsidiaries. Other

trademarks or service marks contained in this presentation are the property of the

respective companies with which they are associated.

This presentation is for informational and discussion purposes only and should not be

construed as a commitment of Magento, Inc. or eBay Enterprise (“eBay Enterprise”) or of

any of their subsidiaries or affiliates. While we attempt to ensure the accuracy,

completeness and adequacy of this presentation, neither Magento, Inc., eBay Enterprise

nor any of their subsidiaries or affiliates are responsible for any errors or will be liable for

the use of, or reliance upon, this presentation or any of the information contained in it.

Unauthorized use, disclosure or dissemination of this information is expressly prohibited.

What’s on for today?

• Introduction

• M2 and M1, onward to the good news!

• That’s nice but what exactly did you do?

• What about the client side?

• Performance is only part of the picture

01. Leading OffHow we look at the problem

Performance and

Magento 2 Approach

• Tendency to conflate server-side

performance with overall

performance

– 70% of the user experience is

waiting for the browser to render

• Change the testing tool chain

– Add WebPageTest for client side

testing

• Enforce client side best practices

– YSlow

– PageSpeed

Tooling Sounds Nice But…

Test Plan Description

Performance Acceptance Basic browse/checkout scenarios. Part of Definition of

Done for each sprint

Client Side Performance Multiple shop, checkout and guest checkout scenarios

Server Side Performance Multiple shop, checkout and guest checkout scenarios

Throughout Multiple shop, search, checkout, guest checkout and

store admin scenarios to point of web node saturation

02. Getting to the good part‘Cause it’s pretty sweet!

Consumer Shopping Experience

0

0.5

1

1.5

2

2.5

3

BrowsingScenario

En

d-t

o-e

nd

tim

e (

sec)

M1

M2

• 25% faster out of the box

• 15% on Catalog Browsing

• 45% on Addition to Cart

• Relevant for any Catalog

page

• Category

• Product

• CMS page

• Result is independent of load

Consumer Shopping Details

0

0.2

0.4

0.6

0.8

1

1.2

Home Page Category View Product View Adding productto Cart

En

d-t

o-e

nd

tim

e (

sec)

M1

M2

Purchase Experience

0

1

2

3

4

5

6

7

8

CustomerCheckout

GuestCheckout

En

d-t

o-e

nd

tim

e (

sec)

Scenario

M1

M2

• Already on M1 level or faster• Parity on Customer Checkout

• Slightly faster on Guest Checkout

• More performance improvements• Asynchronous emailing

• Checkout rendering in browser

Guest Checkout Details

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

Start Guest mode AddressSelection

Shipping Payment PlacingOrder

En

d-t

o-e

nd

tim

e (

se

c)

Checkout Steps

M1

M2

Customer Checkout Details

0

0.5

1

1.5

2

2.5

Start Login AddressSelection

Shipping Payment PlacingOrder

En

d-t

o-e

nd

tim

e (

se

c)

Checkout steps

M1

M2

03. How’d you do that?The old fashioned way of course!

Starting out the usual way

Classic server side profiling and fixing

• Don’t ask for things you don’t need

– Eliminate unnecessary requests

– Eliminate unnecessary DB queries

• Make the big ones smaller

– Decompose large objects

– Eliminate unnecessary logic

• Cache what you can

– Reusable objects

– Object metadata

More in depth solutions

• Single tenant compilation

– Pre-generate files

– Pre-process system configuration

• Focus on the ObjectManager

– Minimize and streamline logic

• Interceptors

– Limit to methods with declared plug-ins

• Layout improvements

– Cache structure

– Change internal representation

Going further with the server

Extending the tech stack

• Support for Varnish 4 out of the box

• Compatibility with HHVM

• Working closely with Zend to prepare

for PHP 7

Looking outside the

codebase

Incremental Improvements Over Time

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Home Page Category View Product View Adding Productto Cart

Se

rve

r s

ide

re

sp

on

se

tim

e (

se

c)

M2, August 2014

M2, April 2015

Incremental Improvements Over Time

0

2

4

6

8

10

12

14

Customer Checkout Guest Checkout

To

tal re

sp

on

se t

ime (

sec)

M2, August 2014

M2, April 2015

04. Didn’t you mention client side? Loads of changes here

Optimizing for

the BrowserBroad range of solutions

• Reduce blocking operations– Asynchronous add to cart

– Eliminate in-line JavaScript

• Make the JavaScript smaller– JavaScript bundling

– Lazy evaluation

• Reduce the amount of storefront content– Minification of HTML/CSS/JS

– Improve image compression at upload time

• Stick with caching as theme– Cache static content in browser

– Fine tune cache expiry settings

Coming Attractions

Still opportunities to leverage

• Checkout is harder to cache

– Render in the browser

• Private data on the storefront

– Same techniques as checkout

• For the GA release

– Lightweight Magento object

– Rendering improvements

– Keep the focus on client side scores

05. Perf. isn’t the whole story Because who needs limits?

The High Level View

Catalog Checkout

Product Management

System

Order Management

System

Scaling at the DB Level

Scalable Checkout (EE)

Scalable OMS (EE)

Catalog DB

Main DB Orders DB

Checkout DB

Scaling Functionality

Feature Status Version

Catalog Database Separation R/W By GA release EE

Standalone Database for Checkout Complete EE

Concurrent Order Management (50+) Complete CE/EE

Asynchronous Grid Fulfillment Complete CE/EE

Standalone Database for OMS Complete EE

MySQL Cluster support (Checkout / OMS) Complete EE

Concurrent Product Management (25+) Complete CE/EE

Concurrent Real Time Product Mgmt (25+) In progress EE

How’s It Working Out?

Catalog

500K views per hour

Checkout

42K orders per hourM1

M2Catalog

10M views per hour

Checkout

90K orders per hour

06. Questions?

Predictable Questions

Server Type Quantity Configuration

Web Node 6 8 Core, 32 GB RAM

DB Node 2 8 Core, 32 GB RAM

Redis 1 2 Core, 8 GB RAM

Varnish 1 8 Core, 16 GB RAM

Load Balancer 1 2 Core, 4 GB RAM

Throughput Measurement Environment

Predictable Questions (continued)

Server Type Quantity Configuration

Bare Metal Server – web,

MySQL, Varnish (M2) or

FPC (M1), CentOS 6.4

1 24 Core, 64 GB RAM, web root mounted

on RamDisk

Client Machine – Google

Chrome, WebPageTest

Agent, Windows Pro 7

1 4 Core, 8GB RAM

End to End Measurement Environment