14. Hardware stack example Linux, Apache PHP R/W MySQL master Front server 1 MySQL server 1 memcached
15. 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
16.
17.
18.
Hinweis der Redaktion
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
![Agenda ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)