Performance, Scale - Magento Deep Dive - T... · Performance and Magento 2 Approach • Tendency to...
Transcript of Performance, Scale - Magento Deep Dive - T... · Performance and Magento 2 Approach • Tendency to...
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