IT training full stack web performance khotailieu

27 Get Synthetic Web Performance Results 27 Trial a CDN for Free 27 Trial an Application Performance Management Tool for Free 28 Embrace Full-Stack Development and DevOps 28 iii... One w

Incapsula helps you take care of business by simplifying ops and protecting your web apps Our PCI-certified and SOC 2 compliant cloud service is easy to deploy, intelligent and scalable

We secure websites from top web threats like SQL injections, XSS and web scraping so your customers can go about their business with confidence.

Secure and Accelerate

Your Website

Find out more about what Incapsula can do for your business

https://www.incapsula.com/web-application-security/

Tom Barker

Full Stack Web Performance

Boston Farnham Sebastopol Tokyo

Beijing Boston Farnham Sebastopol Tokyo

Beijing

[LSI]

Full Stack Web Performance

by Tom Barker

Copyright © 2017 O’Reilly Media, Inc All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://oreilly.com/safari) For more information, contact our corporate/institutional sales department: 800-998-9938 or

corporate@oreilly.com.

Editor: Meg Foley

Production Editor: Shiny Kalapurakkel

Copyeditor: Octal Publishing, Inc.

Interior Designer: David Futato

Cover Designer: Karen Montgomery

Illustrator: Rebecca Demarest July 2017: First Edition

Revision History for the First Edition

2017-06-16: First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc Full Stack Web

Performance, the cover image, and related trade dress are trademarks of O’Reilly

Media, Inc.

While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limi‐ tation responsibility for damages resulting from the use of or reliance on this work Use of the information and instructions contained in this work is at your own risk If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsi‐ bility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents

Introduction v

1 Client-Side 1

Use a Speed Test 1

Now Integrate into Continuous Integration 5

Use Log Introspection for Real User Monitoring 6

Tell People! 8

Summary 9

2 Accomplishing Web Performance Wins via Infrastructure 11

Using a CDN 11

Edge Caching: Serving Your Application as Close as Possible to Your User 12

Make Requests to the Fastest Possible Origin 13

Using a Cloud Provider 14

Summary 17

3 Operationalize Performance 19

Setting Up an APM 19

Using an APM to Troubleshoot Performance Issues 20

Summary 25

4 Next Steps 27

Get Synthetic Web Performance Results 27

Trial a CDN for Free 27

Trial an Application Performance Management Tool for Free 28

Embrace Full-Stack Development and DevOps 28

iii

We are in the midst of another tidal change in the software engi‐neering and IT industries This has been going on for a number ofyears already, but like the frog in the pot that doesn’t notice thewater slowly beginning to boil around him, some of us might nothave noticed the transitions in our environment We’ve overlookedthese transitions because there have been many smaller ones that wejust adjusted to, that accumulated to be a big significant change Ormaybe it’s just that the ideas behind these changes have been talkedabout for quite some time, but it’s only relatively recently that theyhave coalesced into actionable patterns that are easy to implementand reproduce

I was reminded of this recently because some of my teams—specifi‐cally those that are working on products that we made three or moreyears ago—are migrating their products from physical datacenters

to cloud platforms

Think about that for a minute: three or four years ago we were start‐ing new projects first by requesting nodes—in some cases, virtualmachines (VMs) on a hypervisor, and in other cases actual physicalboxes—and IP blocks, waiting days, or in most cases, even weeks forthe boxes to be configured Today, of course, we run a script and ourcloud platform of choice spins up nodes preconfigured with theimage that we want nearly instantaneously

Our notions of web performance and capacity planning, too, havechanged Now if we need to scale a cloud web-native application tohandle spikes in usage, it’s a matter of only selecting a checkbox andpaying for the scale that we need There are also new challenges inthe field that we are just now discovering, and coming up with

v

workarounds for, like the appropriate use of availability zones (thinkabout the Amazon Web Services outage of 2017 that brought down asignificant portion of the web) or even how to use multiple cloudservice providers to serve a single property.

Even our organizational identities are changing If someone is a webdeveloper, why can’t they learn to request and configure VMs fromtheir cloud provider? And if they are setting up the machines onwhich their code resides, and maybe even the firewall rules, why notthen set up their own log consumption flow, then at that point arethey still just a web developer, or are they maybe a full-stack devel‐oper or even a DevOps engineer?

These are just a few examples of how a concept like DevOps haschanged the day-to-day activities of our work routines

Who This Book Is For

DevOps encapsulates different things to different groups Someinterpret it as an integrating of traditional infrastructure or Opsroles into a development team, whereas others bundle security inthere and call it DevSecOps Maybe some groups have differentinterpretations of what Ops means, defining it as incorporating notjust infrastructure but also production support roles

As such, this book is for anyone who needs to think about and dealwith performance in a DevOps environment From web developer,

to DevOps engineer, to engineering manager and architect, thisbook is intended for you

This book has set out to address how web performance fits into thismodern landscape of the all-encompassing cross-functional DevOpsteam You’ll find the topics organized into three high-level areas offocus in a product development group:

vi | Introduction

These are the practices you put in place to monitor and alert onthe health of your applications

This book also presents significant but quick wins throughout That

is a relative term, but the way that I have approached this is to takeadvantage of existing tools and libraries that are fast to integratewith but have huge payoffs Depending on your architecture andteam makeup, the level of effort for each of these solutions or rec‐ommendations should be measured only in days and weeks, notmonths for the most part (at least from my reckoning; your mileagemay vary)

Introduction | vii

CHAPTER 1

Client-Side

In web development, the client-side is the code that runs on the

users’ hardware—either in browsers on their laptops, web views in amobile app on their phones, or perhaps even in a render engine run‐ning on the set-top box in their living rooms

There is a huge body of written work around improving web perfor‐

mance, beginning with Steve Souders’ seminal book, High Perfor‐

mance Web Sites, but the landscape of client-side performance

changes rapidly, in large part because of proactive performanceimprovements implemented by the browser makers themselves, aswell as the work being done at the standards level

So, as busy product development engineers and engineering leaders,how do we keep up with the changes and reconcile the differencesacross browsers? One way is to rely on synthetic performance test‐ing using one or more of the tools available today

Use a Speed Test

Speed tests, or performance testing tools, are applications that load asite and run a battery of tests against it, using a dictionary of perfor‐mance best practices as the criteria for these tests These tools areconstantly updated and should reflect and test against the currentbest practices They keep track of changing practices, so you don’tneed to

1

1 Available at https://www.webpagetest.org This is run by Patrick Meenan and is used to power such sites as the HTTP Archive.

Two terms you’ll see around performance testing are

synthetic testing and real user metrics Real user metrics

is data gathered from actual users of your site, which

you harvest, analyze, and learn from to see what your

audience’s actual experience is like Synthetic testing is

when we run tests in a lab to identify performance pit‐

falls before we release to production Speed tests are

what we would call synthetic tests

There are many performance testing tools on the market, frombrowser-integrated tools like YSlow, or free web applications likeWebPageTest, to full enterprise solutions My personal favorite webperformance testing tool is WebPageTest.1 You can use the hostedsite as is, or, if you want, you can download the project and run iton-premises using so-called private instances, so that you can use it

to test your preproduction environments that are usually not pub‐licly accessible

WebPageTest essentially employs a number of agents around theworld that can run a huge variety of devices to go to your site andgive you the performance metrics from each run Figure 1-1 showsthe WebPageTest homepage

Note the Test Location drop-down menu That’s where you chooseyour agent You can use this to choose where the test is run, but alsowhat hardware and operating system on which it is run You alsocan choose a number of other options, including the type of connec‐tion to use, the different browsers that are available to that particularagent, and whether you want to test just the initial uncached view ofthe site or also additional cached versions for comparison

2 | Chapter 1: Client-Side

2 You can find more information about Speed Index at https://sites.google.com/a/webpaget est.org/docs/using-webpagetest/metrics/speed-index.

Figure 1-1 The WebPageTest homepage

Each test you run returns results that include the following, amongother things:

• A letter rating of A–F, which describes the site’s performance

• A high-level readout of your most important metrics such astime to first byte, Speed Index,2 number of HTTP requests, andtotal size of payload for site (see Figure 1-2)

• Waterfall charts that show the order and timing of each assetdownloaded

• A chart that shows the ratio of what asset types make up yourpage’s payload

Use a Speed Test | 3

Figure 1-2 The results of my WePageTest run (the F’s in my score are because of content loaded onto my page from an advertising partner)

Also included in your results are details of your rating that outlinethe items that were flagged against the criteria of the test Thesedetails are essentially a checklist to follow to improve your site’s webperformance See Figure 1-3 for an example of these Do you comeacross some images that aren’t compressed? Compress them Do younotice some files that aren’t served up gzipped? Set up HTTP com‐pression for those responses

Figure 1-3 Flagged items

Let the tool do the analysis so that you can manage the implementa‐tion of its findings

4 | Chapter 1: Client-Side

Now Integrate into Continuous Integration

Performance testing tools are great, but how do you scale them foryour organization? It’s not practical to remember to run these tests

ad hoc What you need is a way to integrate them into your existingcontinuous integration (CI) environment

Luckily WebPageTest provides an API All you need is an API key,which you can request at http://www.webpagetest.org/getkey.php.Using the API, you can write a script in your language of choice andprogrammatically run tests against WebPageTest The tests can take

a little while to run, so your script will need to poll WebPageTest tocheck the status of the test until the test is complete When the test iscomplete, you can iterate through the response and pull out eachresult Figure 1-4 presents a high-level architecture of how thisscript might function

Figure 1-4 High-level architecture of how the script might function

After you have the result, you can do any number of things: you cancreate charts with those results with a tool such as Grafana (https:// grafana.com), you can store them locally, and you can integrate theseresults into your CI software of choice (see Figure 1-5) Imagine fail‐ing a build because the changes introduced a level of latency thatyou deemed unacceptable and holding that build until the perfor‐mance impact has been addressed!

Now Integrate into Continuous Integration | 5

Figure 1-5 Integrating your results into your CI software

Of course, as with anything that breaks the build, the conversationswill need to be had around whether the change is worth the impactand do we raise the accepted latency even just temporarily to get thisfeature out—but still, at least these conversations are happening andthe team isn’t trying to figure out what change affected performanceafter the fact and how to deal with this while your app is live in pro‐duction

Use Log Introspection for Real User

Monitoring

Real User Monitoring is the practice of recording and

examining actual user interactions and deriving the

performance data from these interactions This is gen‐

erally a more useful metric to report than synthetic

results because the numbers reflect real experiences of

your actual users

So, this is great for testing during development, but how do youquantify your performance in production with real users? An

answer to that is to use log introspection Log introspection really just

means harvesting your server and error logs into a tool such asSplunk or ELK (Elasticsearch, Logstash, and Kibana), which allowsyou to query and build monitors, alerts, and dashboards against thisdata, as illustrated in Figure 1-6

6 | Chapter 1: Client-Side

Figure 1-6 Dashboards, monitors, and alerts against data

But, wait, you might be saying: aren’t logs primarily about monitor‐ing system performance? True, logs are generated on the backend,and traditionally the data in these logs pertain to requests againstthe server Although they’re hugely useful to gather HTTP responsecodes and ascertain fun things like vendor API Service-Level Agree‐ment compliance, they do not naturally lend themselves to captur‐ing client-side performance metrics

Luckily one of my friends and colleagues, John Riviello, has created

an open source JavaScript library named Surf-N-Perf that capturesthese metrics on the client-side and allows you to feed them to anendpoint you define Some of these metrics are data points to allowyou to see when a page has started to render, when it finishes ren‐dering, or when the DOM is able to accept interaction These are allkey milestones to evaluate a user’s actual experience

The library uses the performance metrics available to the window.performance object (documentation for which is available at

Use Log Introspection for Real User Monitoring | 7

Figure 1-7 Creating an endpoint that takes the request and writes it to your logs

This allows you to see what the actual real performance numbers arefor your customers From there, you can slice this into percentilesand say with certainty what the actual experience is for the vastmajority of our users This also allows you to begin diagnosing andfixing other issues that might not have been caught by your syn‐thetic testing We talk more about this in Chapter 3

Tell People!

Your application gets mostly straight A’s in the synthetic tests yourun, any performance affecting changes are caught and mitigatedbefore ever getting to production, and your dashboards show sub‐second load times for the 99th percentile of your actual users Con‐gratulations! Now what? Well, first you operationalize, which we talkabout in Chapter 3, but after that you advertise your accomplish‐ments!

Chances are, your peers and management won’t proactively notice,though your users and your business unit should What do you do

8 | Chapter 1: Client-Side

with all of these fantastic success stories you have accumulated alongwith the corroborating metrics? Share them.

Incorporate your performance metrics into your regular statusupdates, all hands, and team meetings Challenge peer groups toimprove their own metrics Publish your dashboards across yourorganization Better performance for everyone only benefits yourcustomers and your company, so collaborate with your business unit

to quantify how this improved performance has affected the bottomline and publish that

Summary

In this chapter, we looked at using speed tests to keep up with theever-changing landscape of client-side web performance best practi‐ces For extra points, and to realistically scale this for an organiza‐tion, we talked about automating these tests and integrating theseautomated tests into our CI environment

We also talked about utilizing our log introspection software, alongwith an open source library such a Surf-N-Perf, to capture ouractual real user metrics around client-side performance How wethen diagnose and improve those numbers in production is thefocus of Chapter 3

Summary | 9