drupal performance and scalability

Click here to load reader

Post on 27-Aug-2014




2 download

Embed Size (px)


In this session we will present an overview from the point of view 'system that implementative on how to get the best performance from your drupal application. We will also show examples of use cases for drupal scalable infrastructure.


  • About Stefano Drupal developer since 2007 Twinbit co-founder ILDN founder Im a geek and i love Open Source software @stefanomainardi [email protected]
  • About Marco web and open source consultant and developer interested in knowledge management, GIS, and integration of systems with CMS Twinbit co-founder @marcogiaco [email protected]
  • Agenda Why speed is so important Tips for frontend optimization Tips for backend optimization Q&A time (we hope!)
  • What is performance?
  • The delay perceived between an action (e.g. click) and a meaningful response What is performance?
  • Performance is money Why do we care about it?
  • Why speed is so important?
  • some numbers
  • 1 Second decrease page load time
  • Amazon's calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Source: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/
  • Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day Source: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/
  • WHAT??
  • Performance golden rule
  • 80-90%of the end-user response time is spent on the frontend.
  • Start there. 80-90%of the end-user response time is spent on the frontend. Source: http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
  • But rst, the horrible truth about Drupal
  • Drupal is Database intensive! ! Memory intensive! ! Can easily become a resource hog
  • Why most drupal sites are slow? Poor frontend implementation! ! Slow mysql queries! ! Serving dynamic contents to anonymous ! users! ! Module bloat (open buffet syndrome)
  • Lets focus on frontend
  • 1. When we request a URL a DNS lookup is done 2. Download the html and start reads from top 3. CSS Block rendering. The browser starts rendering once it has all the style declarations 4. Javascript blocks downloads. Make sure to serve js at last 5. Circa 4/8 assets (images / js / css /fonts) are downloaded in parallel from the same domain www.twinbit.it ? IP = How does a browser work?
  • Our goals 1. Put CSS on top (it blocks rendering) 2. Put JS on bottom (it blocks downloads) 3. Minimize the number of requests (CSS / js / images, fonts) 4. Send less data as possible 5. Spread your assets over several domains (CDN)
  • Put javascript on footer
  • Remove unneeded css Using hook_css_alter() to limit amount of requests
  • Remove unneeded css Using hook_css_alter() to limit amount of requests
  • Use aggregation Built-in aggregation
  • Use aggregation Advanced CSS/JS Aggregation module http://drupal.org/project/advagg or smart solution
  • Use aggregation Advanced CSS/JS Aggregation module http://drupal.org/project/advagg Fully cached CSS/JS assets allow for zero le I/O if the Aggregated le already exists. Results in better page generation performance On demand generation of CSS/JS Aggregates. If the le doesn't exist it will be generated on demand. Gzip support. All aggregated les can be pre-compressed into a .gz le and served from Apache. This is faster then gzipping the le on each request.
  • Use aggregation Advanced CSS/JS Aggregation module http://drupal.org/project/advagg built-in support for ! ! HTTP Parallel Request & Threading Library https://drupal.org/project/httprl
  • Image requests 1. Sprites: One file for all UI elements (1 request) 2. Use automatic tools like Compass for generate sprites http://compass-style.org/help/tutorials/spriting/ 3. Optimize imageshttps://drupal.org/project/imageapi_optimize 4. Use font-based icons https://drupal.org/project/fontello
  • Keep in mind to send less data to servers, ever!
  • SPREAD your assets over several domains
  • use CDN module https://drupal.org/project/cdn
  • 2 tips 1 . DNS Prefetching 2. Cookie-less domain set in settings.php the variable $cookie_domain = www.twinbit.it
  • Monitor your application
  • Monitor your application YSlow Chrome and Firefox developer tools, are your best friends Google page speed tools or use external services like New relic and know the tools
  • take away Cache saves the cache cache everything at every level
  • Lets focus on backend thank you for now!
  • Caching
  • Anonymous vs authenticated Identify the type of your application in order to apply appropriate caching policies. ! The more static the application is the more it will be served by the client- side caches. ! Highly dynamic application will need efficient application-side caching.
  • Clustered architecture
  • Reverse proxy A proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though they originated from the server itself. ! Varnish is widely adopted, open source and natively supported by Drupal 7.x from 300x to 1000x faster serves static pages and assets powerful configuration language ESI (https://drupal.org/project/esi) can act as load balancer More links https://drupal.org/node/1054886 https://drupal.org/project/varnish https://www.varnish-cache.org/trac/wiki/VarnishAndDrupal !
  • Web servers Drupal configuration / coding ! use static caching $foo = &drupal_static(__FUNCTION__); use cache_set/cache_get disable unneeded modules avoid variable_set() in frontend pages and cache invalidation keep app logic away from template, use hook_preprocess functions dont reinvent the wheel! api.drupal.org is your best friend! keep drupal performance configuration in settings.php ! System ! configure Apache MaxClients ((System RAM) (RAM used by other processes)) / (httpd process size) = MaxClients KeepAliveTimeout < 5 sec ! use APC apc.stat ~ 0 apc._num_files_hint > 1000 ! use Nginx if no proxy or CND More links https://groups.drupal.org/high-performance
  • Web servers: more is better
  • ! VM-C1: 1 cpu, 2 GB ram VM-C2: 2 cpu, 4 GB ram VM-C3: 4 cpu, 8 GB ram Web servers: more is much better
  • Session management Drupal is saving sessions to database. This can be used in a cluster but we want to save database queries. ! To do this we can use different solutions: ! ! ! ! Memcache Redis MongoDB pros very easy and fast very fast native replication cons no native replication no native replication cluster configuration Drupal compatibility mature medium medium
  • Application caching Drupal has several caches, by default stored in database. To avoid loading the database we can still use different solutions: ! memcache / redis mongodb ! ! More links https://drupal.org/project/memcache https://drupal.org/project/mongodb http://www.mongodb.org/ ! ! !
  • Memcache tips ! exclude cache_form and cac