Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scaling PHP

Scaling PHP

Scaling PHP presented at PHPBulgaria 2016

6d9b2c900628962b16a5cb5e4e73990e?s=128

Dustin Whittle

October 08, 2016
Tweet

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
  10. None
  11. PERFORMANCE DIRECTLY IMPACTS THE BOTTOM LINE

  12. None
  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
  51. None
  52. None
  53. None
  54. None
  55. LEVERAGE HTTP CACHING

  56. None
  57. None
  58. EXPIRES OR INVALIDATION

  59. EXPIRATION

  60. None
  61. None
  62. VALIDATION

  63. None
  64. None
  65. EXPIRATION AND INVALIDATION

  66. None
  67. None
  68. None
  69. None
  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!

  77. None
  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

  81. None
  82. UPROFILER + XHPROF + GUI

  83. None
  84. None
  85. None
  86. None
  87. None
  88. None
  89. None
  90. None
  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

  104. None
  105. None
  106. None
  107. None
  108. None
  109. None
  110. None
  111. None
  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