Scaling PHP

Scaling PHP presented at PHPBulgaria 2016

Transcript

1. SCALING PHP Dustin Whittle
2. 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.
3. AGENDA • Why performance matters? • The problems with PHP • Best practice designs • Distributed data caches with Redis and Memcached • Doing work in the background with queues • Http caching and a reverse proxy with Varnish • Using the right tool for the job • Tools of the trade • Xdebug + WebGrind • XHProf + XHProf GUI • AppDynamics • Google PageSpeed • Architecture not applications
4. %645*/
   8)*55-& EVTUJOXIJUUMFDPN
   !EVTUJOXIJUUMF
   4BO
   'SBODJTDP
   $BMJGPSOJB
   64"
   6CFS
   "QQ%ZOBNJDT
   ,XBSUFS
   4FOTJP-BCT
   :BIPP
   l
   5FDIOPMPHJTU
   5SBWFMFS
   1JMPU
   4LJFS
   %JWFS
   4BJMPS
   (PMGFS
5. WHAT I HAVE WORKED ON • Developer Advocate @
 • Developer Evangelist @
 • Consultant & Trainer @
 • Developer Evangelist @
6. DID YOU KNOW FACEBOOK, YAHOO, ZYNGA, TUMBLR, ETSY, AND WIKIPEDIA WERE ALL STARTED ON PHP?
7. WHY DOES PERFORMANCE MATTER?
8. WHEN MOZILLA SHAVED 2.2 SECONDS OFF THEIR LANDING PAGE, FIREFOX DOWNLOADS INCREASED 15.4% (60 million more downloads)
9. AMAZON AND WALMART INCREASED REVENUE 1% FOR EVERY 100MS OF IMPROVEMENT
11. PERFORMANCE DIRECTLY IMPACTS THE BOTTOM LINE
13. •Performance is key to a great user experience •Under 100ms is perceived as reac$ng instantaneously •A 100ms to 300ms delay is percep$ble •1 second is about the limit for the user's flow of thought to stay uninterrupted •Users expect a site to load in 2 seconds •AXer 3 seconds, 40% will abandon your site. •10 seconds is about the limit for keeping the user's a*en$on •Modern applicaDons spend more Dme in the browser than on the server-side
14. Login Flight Status Search Flight Purchase Mobile Big data SOA NOSQL Cloud Agile Web Application complexity is exploding
15. TREAT PERFORMANCE AS A FEATURE!
16. PHP IS SLOWER THAN JAVA, C+ +, ERLANG, SCALA, AND GO!
17. HTTP://PHPSADNESS.COM/
18. ...AND PHP HAS SOME SERIOUS DESIGN ISSUES AND INCONSISTENCIES!
19. ...BUT THERE ARE WAYS TO SCALE TO HANDLE HIGH TRAFFIC APPLICATIONS
20. PHP IS NOT YOUR PROBLEM!
21. SCALABILITY = ARCHITECTURE != CODE OPTIMIZATIONS
22. WHAT VERSION OF PHP DO YOU RUN?
23. UPGRADE YOUR PHP ENVIRONMENT TO 2016! PHP7 is twice as fast as PHP5
24. USE COMPOSER TO STAY UP TO DATE
25. NGINX + PHP-FPM
26. USE AN OPCODE CACHE!
27. PHP 5.5+ HAS OPCACHE
28. USE AUTOLOADING AND PSR-0
29. SYMFONY CLASSLOADER COMPONENT WITH CACHING
30. SCALING BEYOND A SINGLE SERVER IN PHP
31. OPTIMIZE YOUR SESSIONS!
32. THE DEFAULT IN PHP IS TO PERSIST SESSIONS TO DISK
33. IT IS BETTER TO STORE SESSIONS IN A DATABASE
34. EVEN BETTER IS TO STORE IN A DATABASE WITH A SHARED CACHE IN FRONT
35. PECL INSTALL MEMCACHED
36. session.save_handler = memcached session.save_path = "10.0.0.10:11211,10.0.0.11:11211,10.0.0.12:11211" memcached.sess_prefix = “session.” memcached.sess_consistent_hash = On memcached.sess_remove_failed = 1 memcached.sess_number_of_replicas = 2 memcached.sess_binary = On memcached.sess_randomize_replica_read = On memcached.sess_locking = On memcached.sess_connect_$meout = 200 memcached.serializer = “igbinary”
37. THE BEST SOLUTION IS TO LIMIT SESSION SIZE AND STORE ALL DATA IN A SIGNED OR ENCRYPTED COOKIE
38. Scaling server-side applications • Caching - Cache as much on the client-side and server side as possible (javascript, css, images, fonts, content). • Leverage a CDN + browser caching • Use a reverse proxy cache on the server side • Queuing - Do not delay the user experience for tasks that can be executed in the background • Async - Optimize work to execute concurrently / asynchronously
39. LEVERAGE AN IN-MEMORY DATA CACHE
40. MEMCACHED.ORG
41. REDIS.IO
42. •Any data that is expensive to generate/query and long lived should be cached •Web Service Responses •HTTP Responses •Database Result Sets •ConfiguraDon Data
43. GUZZLE HTTP CLIENT HAS BUILT- IN SUPPORT FOR CACHING WEB SERVICE REQUESTS AND PSR-7
44. $memcache = new Memcache(); $memcache->connect('localhost', 11211); $memcacheDriver = new Doctrine\Common\Cache\MemcacheCache(); $memcacheDriver->setMemcache($memcache); $client = new Guzzle\H:pClient(‘h:p://www.test.com/’); $cachePlugin = new Guzzle\Plugin\Cache\CachePlugin(array( ‘storage’ => new Guzzle\Plugin\Cache\DefaultCacheStorage( new Guzzle\Plugin\Cache\DoctrineCacheAdapter($memcacheDriver) ) )); $client->addSubscriber($cachePlugin); $response = $client->get(‘h:p://www.wikipedia.org/’)->send(); $response = $client->get(‘h:p://www.wikipedia.org/’)->send();
45. DOCTRINE ORM FOR PHP HAS BUILT-IN CACHING SUPPORT FOR MEMCACHED AND REDIS
46. $memcache = new Memcache(); $memcache->connect('localhost', 11211); $memcacheDriver = new Doctrine\Common\Cache\MemcacheCache(); $memcacheDriver->setMemcache($memcache); $config = new Doctrine\ORM\ConfiguraDon(); $config->setQueryCacheImpl($memcacheDriver); $config->setMetadataCacheImpl($memcacheDriver); $config->setResultCacheImpl($memcacheDriver); $enDtyManager = Doctrine\ORM\EnDtyManager::create(array(‘driver’ => ‘pdo_sqlite’, ‘path’ => __DIR__ . ‘/db.sqlite’), $config); $query = $em->createQuery(‘select u from EnDDesUser u’); $query->useResultCache(true, 60); $users = $query->getResult();
47. DO BLOCKING WORK IN BACKGROUND TASKS VIA QUEUES
48. •Resque •Gearman •RabbitMQ •Kawa •Beanstalkd •ZeroMQ •AcDveMQ
49. RESQUE
50. •Any process that is slow and not important for the h:p response should be queued •Sending noDficaDons + posDng to social accounts •AnalyDcs + InstrumentaDon •UpdaDng profiles and discovering friends from social accounts •Consuming web services like Twi:er Streaming API
55. LEVERAGE HTTP CACHING
58. EXPIRES OR INVALIDATION
59. EXPIRATION
62. VALIDATION
65. EXPIRATION AND INVALIDATION
70. SYMFONY HTTPFOUNDATION COMPONENT WITH HTTP CACHING
71. use Symfony\Component\H:pFoundaDon\Response; $response = new Response(‘Hello World!’, 200, array(‘content-type’ => ‘text/html’)); $response->setCache(array( ‘etag’ => ‘a_unique_id_for_this_resource’, ‘last_modified’ => new DateTime(), ‘max_age’ => 600, ‘s_maxage’ => 600, ‘private’ => false, ‘public’ => true, ));
72. use Symfony\Component\H:pFoundaDon\Request; use Symfony\Component\H:pFoundaDon\Response; $request = Request::createFromGlobals(); $response = new Response(‘Hello World!’, 200, array(‘content-type’ => ‘text/html’)); if ($response->isNotModified($request)) { $response->send(); }
73. •Varnish •Squid •Nginx Proxy Cache •Apache Proxy Cache
74. USE VARNISH AS A REVERSE PROXY CACHE TO ALLEVIATE LOAD ON YOUR APP SERVERS
75. Caching Best Practices • Use consistent URLs: if you serve the same content on different URLs, then that content will be fetched and stored multiple times. Tip: note that URLs are case sensitive! • Ensure the server provides a validation token (ETag): validation tokens eliminate the need to transfer the same bytes when a resource has not changed on the server. • Identify which resources can be cached by intermediaries: those with responses that are identical for all users are great candidates to be cached by a CDN and other intermediaries. • Determine the optimal cache lifetime for each resource: different resources may have different freshness requirements. Audit and determine the appropriate max-age for each one. • Determine the best cache hierarchy for your site: the combination of resource URLs with content fingerprints, and short or no-cache lifetimes for HTML documents allows you to control how quickly updates are picked up by the client.
76. OPTIMIZE YOUR FRAMEWORK!
78. •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 views and database result sets •Always use a HTTP cache like Varnish
79. Monitor performance on the server-side and client-side
80. XDEBUG + WEBGRIND
82. UPROFILER + XHPROF + GUI
91. PHP AS GLUE
92. BACKEND = JAVA/SCALA/ ERLANG/GO/NODE
    FRONTEND = PHP OR JAVASCRIPT
93. YAHOO! & YPHP Move slow code to PHP extensions
94. FACEBOOK & HHVM
    A drop-in replacement for PHP (mostly)
95. •Upgrade to PHP 7 with Zend OpCache using PHP-FPM + Nginx •Stay up to date with your framework + dependencies (using Composer) •OpDmize your session store to use signed cookies or database with caching •Cache your database and web service access with Memcache or Redis •Do blocking work in the background with queues and tasks using Resque •Use HTTP caching and a reverse proxy cache like Varnish •Profile code with Xdebug + Webgrind and monitor producDon performance with AppDynamics!
96. DON’T FORGET TO OPTIMIZE THE CLIENT SIDE
97. IN MODERN WEB APPLICATIONS MOST OF THE LATENCY COMES FROM THE CLIENT SIDE
98. USE ASSETIC TO OPTIMIZE CLIENT-SIDE ASSETS
99. Common Performance Best Practices • Reduce size of HTTP requests • Optimize stylesheets + javascripts + images + fonts • Leverage gzip compression • Reduce cookie size + use cookie less domains for static assets
100. Common Performance Best Practices • Optimize content • Move stylesheet to head • Move javascript to body close (and eliminate blocking javascript) • Preload components when idle
101. Common Performance Best Practices • Reduce DNS lookups • Reduce network latency with Content Delivery Networks • Use service workers
102. Understanding the impact of HTTP2 • Todays best practices are tomorrows anti-patterns • The limitations of HTTP/1.X forced us to develop various application workarounds (sharding, concatenation, spriting, inlining, etc.) to optimize performance. However, in the process we’ve also introduced numerous regressions: poor caching, unnecessary downloads, delayed execution, and more. • HTTP/2 eliminates the need for these hacks and allows us to both simplify our applications and deliver improved performance. • You should unshard (domains), unconcat (css/javascript), and unsprite your assets (images) • You should switch from inlining to server push • Read Ilya Grigorik awesome book on browser performance - http://hpbn.co/http2
103. GOOGLE PAGESPEED INSIGHTS
112. SCALABILITY IS ABOUT THE ENTIRE ARCHITECTURE, NOT MINOR CODE OPTIMIZATIONS.
113. QUESTIONS?
114. This talk is heavily inspired from: Google PageSpeed Rules Google Web Fundamentals Ryan Tomayko’s “Things Caches Do” Addy Osmani’s “Automating Workflow” Ilya Grigorik “High Performance Browser Networking”
115. FIND THESE SLIDES ON SPEAKERDECK:
     SPEAKERDECK.COM/DUSTINWHITTLE