2013 - Dustin whittle - Escalando PHP en la vida real
1. SCALING PHP IN THE REAL
WORLD!
PHP is used by the likes of Facebook, Yahoo!, Zynga, Tumblr, Etsy, and Wikipedia. How do the
largest internet companies scale PHP to meet their demand? Join this session and find out how
to use the latest tools in PHP for developing high performance applications. We’ll take a look
at common techniques for scaling PHP applications and best practices for profiling and
optimizing performance. After this session, you’ll leave prepared to tackle your next
enterprise PHP project.
Why performance matters?
The problems with PHP
Best practice designs
Doing work in the background with queues
Fronting with http caching and a reverse proxy cache
Distributed data caches with redis and memcached
Using the right tool for the job
Tools of the trade
Opcode Caches
Varnish/Squid and reverse proxy caches
Xdebug + Valgrind + WebGrind
AppDynamics
Architecture not applications
6. Microsoft found that Bing
searches that were 2 seconds
slower resulted in a 4.3%
drop in revenue per user
http://velocityconf.com/velocity2009/public/schedule/detail/8523
7. When Mozilla shaved 2.2
seconds off their landing page,
Firefox downloads increased
15.4%
https://blog.mozilla.org/metrics/2010/04/05/firefox-page-load-speed-%E2%80%93-part-ii/
(60 million more downloads)
8. Making Barack
Obama’s website 60%
faster increased donation
conversions by 14%
http://kylerush.net/blog/meet-the-obama-campaigns-250-million-fundraising-platform/
9. Amazon and Walmart
increased revenue 1% for
every 100ms of improvement
http://www.globaldots.com/how-website-speed-affects-conversion-rates/
10. Amazon and Walmart increased revenue 1% for every 100ms of improvement
http://www.strangeloopnetworks.com/web-performance-infographics/
19. Upgrade your PHP
environment to
2013!
One of the easiest improvements you can make to improve performance and stability is to
upgrade your version of PHP. PHP 5.3.x was released in 2009. If you haven’t migrated to PHP
5.4, now is the time! Not only do you benefit from bug fixes and new features, but you will
also see faster response times immediately. See PHP.net to get started.
Installing the latest PHP on Linux - http://php.net/manual/en/install.unix.debian.php
Installing the latest PHP on OSX - http://php.net/manual/en/install.macosx.php
Installing the latest PHP on Windows - http://php.net/manual/en/install.windows.php
Once you’ve finished upgrading PHP, be sure to disable any unused extensions in production
such as xdebug or xhprof.
21. Use an opcode
cache!
PHP is an interpreted language, which means that every time a PHP page is requested, the
server will interpet the PHP file and compile it into something the machine can understand
(opcode). Opcode caches preserve this generated code in a cache so that it will only need to
be interpreted on the first request. If you aren’t using an opcode cache you’re missing out on
a very easy performance gain. Pick your flavor: APC, Zend Optimizer, XCache, or
Eaccellerator. I highly recommend APC, written by the creator of PHP, Rasmus Lerdorf.
24. Use autoloading
and PSR-0
Many developers writing object-oriented applications create one PHP source file per class
definition. One of the biggest annoyances in writing PHP is having to write a long list of
needed includes at the beginning of each script (one for each class). PHP re-evaluates these
require/include expressions over and over during the evaluation period each time a file
containing one or more of these expressions is loaded into the runtime. Using an autoloader
will enable you to remove all of your require/include statements and benefit from a
performance improvement. You can even cache the class map of your autoloader in APC for a
small performance improvement.
27. Optimize your
sessions!
While HTTP is stateless, most real life web applications require a way to manage user data. In
PHP, application state is managed via sessions. The default configuration for PHP is to persist
session data to disk. This is extremely slow and not scalable beyond a single server. A better
solution is to store your session data in a database and front with an LRU (Least Recently
Used) cache with Memcached or Redis. If you are super smart you will realize you should limit
your session data size (4096 bytes) and store all session data in a signed or encrypted
cookie.
28. The default in PHP
is to persist
sessions to disk
http://www.php.net/manual/en/book.session.php
29. It is better to
store sessions in a
database
http://php.net/manual/en/function.session-set-save-handler.php
30. Even better is to store
in a database with a
shared cache in front
http://php.net/manual/en/memcached.sessions.php
31. The best solution is to
limit session size and
store all data in a signed
or encrypted cookie
http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.encrypt
32. Leverage an inmemory data
cache
Applications usually require data. Data is usually structured and organized in a database.
Depending on the data set and how it is accessed it can be expensive to query. An easy
solution is to cache the result of the first query in a data cache like Memcached or Redis. If
the data changes, you invalidate the cache and make another SQL query to get the updated
result set from the database.
I highly recommend the Doctrine ORM for PHP which has built-in caching support for
Memcached or Redis.
There are many use cases for a distributed data cache from caching web service responses
and app configurations to entire rendered pages.
35. • Any data that is expensive to
generate/query and long lived
should be cached
• Web Service Responses
• HTTP Responses
• Database Result Sets
• Configuration Data
36. Guzzle HTTP client has
built-in support for
caching web service
requests
37. Doctrine ORM for PHP
has built-in caching
support for Memcached
and Redis
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html
38.
39. Do blocking work
in background
tasks via queues
Often times web applications have to run tasks that can take a while to complete. In most
cases there is no good reason to force the end-user to have to wait for the job to finish. The
solution is to queue blocking work to run in background jobs. Background jobs are jobs that
are executed outside the main flow of your program, and usually handled by a queue or
message system. There are a lot of great solutions that can help solve running backgrounds
jobs. The benefits come in terms of both end-user experience and scaling by writing and
processing long running jobs from a queue. I am a big fan of Resque for PHP that is a simple
toolkit for running tasks from queues. There are a variety of tools that provide queuing or
messaging systems that work well with PHP:
42. • Any process that is slow and not
important for the http response
should be queued
• Sending notifications + posting to
social accounts
• Analytics + Instrumentation
• Updating profiles and discovering
friends from social accounts
• Consuming web services like
Twitter Streaming API
47. Leverage HTTP
caching
HTTP caching is one of the most misunderstood technologies on the Internet. Go read the
HTTP caching specification. Don’t worry, I’ll wait. Seriously, go do it! They solved all of these
caching design problems a few decades ago. It boils down to expiration or invalidation and
when used properly can save your app servers a lot of load. Please read the excellent HTTP
caching guide from Mark Nottingam. I highly recommend using Varnish as a reverse proxy
cache to alleviate load on your app servers.
http://tomayko.com/writings/things-caches-do
48.
49. http://tomayko.com/writings/things-caches-do
There are different kinds of HTTP caches that are useful for different kinds of things. I want
to talk about gateway caches -- or, "reverse proxy caches" -- and consider their effects on
modern, dynamic web application design.
Draw an imaginary vertical line, situated between Alice and Cache, from the very top of the
diagram to the very bottom. That line is your public, internet facing interface. In other words,
everything from Cache back is "your site" as far as Alice is concerned.
Alice is actually Alice's web browser, or perhaps some other kind of HTTP user-agent. There's
also Bob and Carol. Gateway caches are primarily interesting when you consider their effects
across multiple clients.
Cache is an HTTP gateway cache, like Varnish, Squid in reverse proxy mode,Django's cache
framework, or my personal favorite: rack-cache. In theory, this could also be a CDN, like
Akamai.
And that brings us to Backend, a dynamic web application built with only the most modern
and sophisticated web framework. Interpreted language, convenient routing, an ORM, slick
template language, and various other crap -- all adding up to amazing developer
51. Expiration
Most people understand the expiration model well enough. You specify how long a response
should be considered "fresh" by including either or both of the Cache-Control: max-age=N or
Expires
headers. Caches that understand expiration will not make the same request until the
cached version reaches its expiration time and becomes "stale".
A gateway cache dramatically increases the benefits of providing expiration information in
dynamically generated responses. To illustrate, let's suppose Alicerequests a welcome page:
52. http://tomayko.com/writings/things-caches-do
Since the cache has no previous knowledge of the welcome page, it forwards the request to
the backend. The backend generates the response, including a Cache-Control header that
indicates the response should be considered fresh for ten minutes. The cache then shoots the
response back to Alice while storing a copy for itself.
Thirty seconds later, Bob comes along and requests the same welcome page:
53. http://tomayko.com/writings/things-caches-do
The cache recognizes the request, pulls up the stored response, sees that it's still fresh, and
sends the cached response back to Bob, ignoring the backend entirely.
Note that we've experienced no significant bandwidth savings here -- the entire response was
delivered to both Alice and Bob. We see savings in CPU usage, database round trips, and the
various other resources required to generate the response at the backend.
54. Validation
Expiration is ideal when you can get away with it. Unfortunately, there are many situations
where it doesn't make sense, and this is especially true for heavily dynamic web apps where
changes in resource state can occur frequently and unpredictably. The validation model is
designed to support these cases.
Again, we'll suppose Alice makes the initial request for the welcome page:
55. http://tomayko.com/writings/things-caches-do
The Last-Modified and ETag header values are called "cache validators" because they can be
used by the cache on subsequent requests to validate the freshness of the stored response
without requiring the backend to generate or transmit the response body. You don't need
both validators -- either one will do, though both have pros and cons, the details of which are
outside the scope of this document.
So Bob comes along at some point after Alice and requests the welcome page:
56. http://tomayko.com/writings/things-caches-do
The cache sees that it has a copy of the welcome page but can't be sure of its freshness so it
needs to pass the request to the backend. But, before doing so, the cache adds the IfModified-Since
and If-None-Match headers to the request, setting them to the original
response's Last-Modified and ETag values, respectively. These headers make the request
conditional. Once the backend receives the request, it generates the current cache validators,
checks them against the values provided in the request, and immediately shoots back a 304
Not Modified
response without generating the response body. The cache, having validated the
freshness of its copy, is now free to respond to Bob.
This requires a round-trip with the backend, but if the backend generates cache validators up
front and in an efficient manner, it can avoid generating the response body. This can be
extremely significant. A backend that takes advantage of validation need not generate the
same response twice.
57. Expiration and
Invalidation
The expiration and validation models form the basic foundation of HTTP caching. A response
may include expiration information, validation information, both, or neither. So far we've seen
what each looks like independently. It's also worth looking at how things work when they're
combined.
Suppose, again, that Alice makes the initial request:
58. http://tomayko.com/writings/things-caches-do
The backend specifies that the response should be considered fresh for sixty seconds and
also includes the Last-Modified cache validator.
Bob comes along thirty seconds later. Since the response is still fresh, validation is not
required; he's served directly from cache:
60. http://tomayko.com/writings/things-caches-do
The cache relies on expiration if at all possible before falling back on validation. Note also
that the 304 Not Modified response includes updated expiration information, so the cache
knows that it has another sixty seconds before it needs to perform another validation request.
61. • Varnish
• Squid
• Nginx Proxy Cache
• Apache Proxy Cache
The basic mechanisms shown here form the conceptual foundation of caching in HTTP -- not
to mention the Cache architectural constraint as defined by REST. There's more to it, of
course: a cache's behavior can be further constrained with additional Cache-Control directives,
and the Vary header narrows a response's cache suitability based on headers of subsequent
requests. For a more thorough look at HTTP caching, I suggest Mark Nottingham's excellent
Caching Tutorial for Web Authors and Webmasters. Paul James's HTTP Caching is also quite
good and bit shorter. And, of course, the relevant sections of RFC 2616 are highly
recommended.
http://www.mnot.net/cache_docs/
62. Use Varnish as a reverse
proxy cache to alleviate
load on your app servers.
63. Optimize your
framework!
Deep diving into the specifics of optimizing each framework is outside of the scope of this
post, but these principles apply to every framework:
Stay up-to-date with the latest stable version of your favorite framework
Disable features you are not using (I18N, Security, etc)
Enable caching features for view and result set caching
64.
65. • Stay up-to-date with the latest stable
version of your favorite framework
• Disable features you are not using (I18N,
Security, etc)
• Always use a data cache like
Memcached/Redis
• Enable caching features for view and
database result set caching
• Always use a http cache like Varnish
67. Taking a large problem
and making it into
manageable smaller
problems
68.
69. In short, sharding means splitting the dataset, but a good sharding function would make sure that related information is located on the same
server (strong locality), since that drastically simply things. A bad sharding function (splitting by type) would create very weak locality, which
will drastically impact the system performance down the road.
73. Facebook &
HipHop
HipHop 1.0 - HPHPc - Transformed subset of PHP code to C++ for performance
HipHop 2.0 - HHVM - Virtual Machine, Runtime, and JIT for PHP
https://github.com/facebook/hiphop-php
https://github.com/facebook/hiphop-php/wiki
74. Learn to how to
profile code for
PHP performance
Xdebug is a PHP extension for powerful debugging. It supports stack and function traces,
profiling information and memory allocation and script execution analysis. It allows
developers to easily profile PHP code.
WebGrind is an Xdebug profiling web frontend in PHP5. It implements a subset of the features
of kcachegrind and installs in seconds and works on all platforms. For quick-and-dirty
optimizations it does the job. Here’s a screenshot showing the output from profiling.
XHprof is a function-level hierarchical profiler for PHP with a reporting and UI layer. XHProf is
capable of reporting function-level inclusive and exclusive wall times, memory usage, CPU
times and number of calls for each function. Additionally, it supports the ability to compare
two runs (hierarchical DIFF reports) or aggregate results from multiple runs.
XHprof
XHGui
AppDynamics is application performance management software designed to help dev and ops
troubleshoot problems in complex production apps.
85. Don’t forget to
optimize the client
side
PHP application performance is only part of the battle
Now that you have optimized the server-side, you can spend time improving the client side!
In modern web applications most of the end-user experience time is spent waiting on the
client side to render. Google has dedicated many resources to helping developers improve
client side performance.
86. In modern web
applications most of the
latency comes from the
client side
In modern web applications most of the end-user experience time is spent waiting on the
client side to render.
87. Google PageSpeed
https://developers.google.com/speed/docs/best-practices/rules_intro
Google PageSpeed Insights – PageSpeed Insights analyzes the content of a web page, then
generates suggestions to make that page faster. Reducing page load times can reduce bounce
rates and increase conversion rates.
Google ngx_pagespeed – ngx_pagespeed speeds up your site and reduces page load time.
This open-source nginx server module automatically applies web performance best practices
to pages, and associated assets (CSS, JavaScript, images) without requiring that you modify
your existing content or workflow.
Google mod_pagespeed – mod_pagespeed speeds up your site and reduces page load time.
This open-source Apache HTTP server module automatically applies web performance best
practices to pages, and associated assets (CSS, JavaScript, images) without requiring that you
modify your existing content or workflow.
