• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Drupalcamp Estonia - High Performance Sites
 

Drupalcamp Estonia - High Performance Sites

on

  • 2,290 views

Rami Järvinen's presentation about high-performance drupal sites at DrupalCamp Estonia.

Rami Järvinen's presentation about high-performance drupal sites at DrupalCamp Estonia.

Statistics

Views

Total Views
2,290
Views on SlideShare
1,745
Embed Views
545

Actions

Likes
0
Downloads
0
Comments
0

8 Embeds 545

http://www.exove.fi 362
http://www.exove.com 125
http://silver.exove.net 28
http://exove.com 23
http://exove2012.local 2
http://www.exove.co.uk 2
http://www.exove.ee 2
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • To tell about some concepts or building parts needed when crafting a high performance sites. Going not to dive deep into these topics, give some keywords for you digg up further.
  • From simple personal pages to large media site or community “platform”.
  • From technical point of view, back to 90’s, serving static pages while making content look like dynamic Most expensive thing a web site can do is to fire up the whole php stack, get something from the database and then render it. It takes time, processor time and memory – and it’s slow. (core is lightweight, but with tens modules on..) Avoid running Drupal’s bootstrap – in fact, try to avoid pulling anything from db or even from disk. We want to push generated or static content as close to the requesting client as possible. The greatest common factor (divisor) for every single user group or individual user. For 100% anon users site it means that every page looks the same for every user. For a site that has some personized content for logged in users, common factor would be the content around the user specific content. Aggregated CSS and JS Apache set up to compress its output with gzip
  • MySQL query cache, its out there, caching internally query results. Opcode cache, fundamental part of PHP configs. Drupal internal caching… block cache, page cache HTTP cache – hanging around on the edge of your server stack, serving content heavenly fast.
  • Surprise if APC its not enabled already..
  • Views caching Code level caching, cache_set / cache_get, static variables, all the fancy stuff happening on the micro level.
  • Never touch the database – image loading might touch because of using imagecache module but that’s for first-time loads too Cached versions are built when node is created or edited or when cron is being run. Configurable - Which node types will be cached, how long, which paths
  • Drupal cache API (cacherouter..), Up to one megabyte Cache bins are in db. Also version with a fallback to db Putting session data to memcache drops the amount of sql queries significantly
  • Drupal 7 or PressFlow needed State of the art Following the concept of bringing the cached data as close to user’s browser as possible. One ESI block may be just fine – but if there’s several of them one page load means several requests to the back end (and thus making bootstrap happen). theme_registry_alter hook
  • The API-caching backend Just a single request to the back-end – it knows by pageID what blocks of data are there and what needs to be filled - also this may be cached in varnish In project approval queue – link to sandbox with more details Comments appreciated
  • More memory, the better
  • When or preferrably before you get into trouble with site performance it’ll be wise to do some profiling. You get a cachegrind file which can viewed with KCacheGrind to analyse profiling data. Static variables for saving results for runtime. In a bad place, even a query taking one second will be troublesome. EXPLAIN, SHOW PROCESSLIST

Drupalcamp Estonia - High Performance Sites Drupalcamp Estonia - High Performance Sites Presentation Transcript

  • High performance drupal sites Rami Järvinen, Exove
  • Agenda
    • About myself
    • Caching
    • Scaling
    • Optimizing
  • About myself, Rami Järvinen
    • Senior developer at Exove
    • Drupal experience from 2006. Been involved with a wide variety of different site projects.
  • Boosting up the performance
    • Drupal ’ s internal architecture
      • Single-controller
      • Loads a lot of code on every pageload
      • Tends to be slower than a pure MVC-model
    • Caching
      • Minimize the CPU usage
      • Minimize the amount of SQL queries
      • Ultimately – avoid running Drupal ’ s bootstrap
    • Serving pages efficiently - it ’ s all about finding the greatest common factor
  • Caching layers
    • MySQL query cache
    • PHP opcode cache
    • Drupal internal caching
    • HTTP cache (reverse proxy)
  • Caching layers – PHP opcode cache
    • Alternative PHP Cache (APC)
    • Caches the compiled bytecode
    • Parsing and compiling PHP code is not needed, if the bytecode is in cache
    • Works generally everywhere and gives a major boost in performance
  • Caching layers – Drupal internal caching
    • Block cache
      • Global / per role / per user
    • Page cache
      • Anonymous users
      • Generally not used for logged in users
    • Code level caching
    • Contrib modules
      • Boost
      • Memcache API and Integration
  • Caching layers - Boost
    • Generated page HTML is saved as a static file
      • Page loads never touch the database
    • For anonymous traffic and sites with a little dynamic content
    • Easy to set up even on a cheap web hotel
      • Enable the module, modify .htaccess and you ’ re done
    • Highly configurable
    • For not yet cached content, serves the page first and saves HTML after that
    • Inbuilt crawler for cache warm-up
  • Caching layers – Memcached
    • High-performance, distributed memory object caching system
    • In-memory key-value store for small chunks of arbitrary data
    • Drop-in replacement for changing Drupal cache backend
      • Instead of saving cached data to DB, it goes to memcached
      • High-traffic sites really need to save the cache to memory
    • Also for session data, Drupal variables etc.
    • Varnish Cache
    • Designed from the ground up as an HTTP accelerator
    • Stores data in virtual memory
    • Configurable with VCL (Varnish Configuration Language)
    • Edge Side Includes (ESI)
      • <esi include= “ /esi/some_content ” />
    • ESI integration module
      • Block template will be changed to instruct Varnish to get block content from e.g. http://example.com/esi/block/xxxxxx
    Caching layers – Reverse proxy
  • Cache Control module
    • An alternative to ESI
    • Cheaper way to display user specific content
    • How it works
      • For all users, we load the page with anonymous content hidden under a throbber
      • JS then checks if the user is logged in (w/ cookie) and (for anonymous users) set the anonymous content visible
      • For logged in users (after JS has checked the login status), it makes a single request to the backend to get the user-specific data for the page
    • http://drupal.org/node/1155312
  • Scaling Drupal
    • MySQL
      • Master-slave setup
      • Direct some of the SQL queries to slave
      • High-performance configurations. There are many good base configs available – start with them.
    • Files
      • Serve static files with Nginx or lighttpd
      • Or use reverse proxy to cache them
    • Scaling by buying more hardware?
  • Hardware stack example Linux, Apache PHP MySQL master Server 1 memcached
  • Hardware stack example Linux, Apache PHP R/W MySQL master Front server 1 MySQL server 1 memcached
  • Hardware stack example Linux, Apache PHP R/W MySQL master Front server 1 MySQL server 1 Linux, Apache PHP Front server 2 MySQL slave MySQL server 2 Varnish HTTP cache 1 Varnish HTTP cache 2 Load balancer Front server R memcached memcached
  • Optimizing
    • Profiling
      • Xdebug or similar profiling tool to see what actually happens during a page load
      • Devel module to print a summary of all database queries executed for page request, including how many times each query was executed and how long each query took
    • SQL bottlenecks
      • Unnecessary repeating of same queries
      • Temporary tables and filesort
      • Table locking if using MyISAM engine in MySQL
    • “ Is there a lot of logged in users or are most of them anonymous? ”
    • “ What kind of things my hosting environment allows me to do? ”
    • There ’ s no single best solution in performance matters
  • Thank you for your time
    • Questions?