Download as PDF, PPTX
Uploaded byTreehouse Agency
Scaling Drupal: Not IF... HOW
This document provides an overview of how to optimize a Drupal site for performance and scalability. It discusses identifying scaling issues, introducing an optimization process through load testing and monitoring tools. Specific techniques covered include enabling the slow query log, using load testing tools like jMeter, reviewing slow query logs, optimizing queries, implementing caching at various levels, and ongoing monitoring with tools like Cacti. Additional measures discussed are database scaling, hardware changes, front-end optimizations like aggregation/compression, and using a content delivery network.
Editor's Notes
- #5 A quick intro of where the session will be goingNote that focus is how to deal with problems on an existing site, rather than building a new site
- #6 People are always asking, \"Does Drupal scale?\"
- #7 All these sites attest, it can!
- #8 Please revise this as needed
- #9 I really don't know what else should go here. Please add as appropriate.
- #11 On Mac / MAMP:/Applications/MAMP/Library/my.cnf
- #13 Discuss:What load testing isWhat jMeter isWhat makes an effective plan
- #16 I:
- #17 jMeter Execution stepsStart slow to make sure the test plan works and makes senseDecide on the number of users you wanna serve in a given period of time. What we expect to get out of thisQueries into the slow query logProblem pages
- #18 jMeter ResultsVariety of reportings available:GraphsResponse time tablesSummary reports, etc.We’ll get into it more in a bit….
- #19 Discuss:How to find logsHow to identify \"slow queries\"--what constitutes slow, how to identify them in the logs
- #20 Discuss:How to find logsHow to identify \"slow queries\"--what constitutes slow, how to identify them in the logs
- #22 One example (the first query on the previous slide)
- #23 Potential pitfalls of queriespoor indexinguseless joins and/or group bysreturning too much dataGood practices for writing querieskeep it simpleknow your databe consistent and plan ahead
- #24 Interesting information:1) Fastest page response2) Slowest page response3) 90% time4) Errors
- #25 By enabling the Devel module:1) View the listing of queries executed2) Make note of any:Slow QueriesQueries that are repeated frequentlyAnything that is being executed yet really shouldn’t be
- #26 Optimize slow queriesLocate if any of the items being executed are the results of blocks or segments that can be cached in some wayWhat ways? - see slide
- #27 Following slides will outline postives and negatives…Types of caching engines:Caching Engines- Standard Drupal Cache
- #32 Types of configurable cache:
- #33 Page cache- positive - allows full pages to be cached, and thus we can serve many more page views on a single server- negative - only works for anonymous users
- #34 Block cache- positive - configurable to work with anonymous users, as well as logged in users- positive - can be page specific, user specific, both or site wide and set to expire at specified intervals- negative - hard to control the expiration of data outside of the specified intervals(i.e. if a block only shows a certain node type, you can set the cache to regenerate when any node type is created)
- #35 Types of programmatic cache:Static variable cache- Programmatic data cache- creating caching strategies within your custom modules- you can also do this in the theme layer (if a particular part on a user's homepage takes a lot of queries or effort to run, you could consider caching it for even 5 minutes)
- #36 only retrieve a single variable once per session- positive - eliminates often duplicate rendered objects- positive - core already uses this in some places so that a second node_load() in a single page request doesn't hit the database again.
- #37 creating caching strategies within your custom modules- you can also do this in the theme layer (if a particular part on a user's homepage takes a lot of queries or effort to run, you could consider caching it for even 5 minutes)
- #38 Discuss:Why ongoing monitoring is importantWhat Cacti isHow Cacti should be used
- #39 - Free!- Monitors various aspect of your site.
- #40 Discuss:Why ongoing monitoring is importantWhat Cacti isHow Cacti should be used
- #41 - Database Scaling
- #42 Not sure how you want to go with this part, if you want to cover each item individually like the others, or talk very briefly about each.Bullets randomly grabbed from notes...please change as you like.
- #43 Front-end performance matters!If a page takes 0.5s to generate and 7s to render, it will still seem slowUse YSlow! to get a score on how fast your website's front-end isJS Aggregation / CompressionSimilar to CSS Aggregation
- #44 YSlow! in actionbefore optimizing:The site is 212.7K
- #45 - With Drupal's JSaggregation turned on,the site already scoresmuch better.- The page has notgotten much smallerin page size (only .6kis saved because coredoesn't compress JS)- The page is almost33% faster to load andour score is muchbetter.
- #46 - CSS sprites let you reuse a single image as a background on multiple objects, again dropping the number of http requests
- #47 Not sure how you want to go with this part, if you want to cover each item individually like the others, or talk very briefly about each.Bullets randomly grabbed from notes...please change as you like.
- #48 the site with all the images, css and js on SimpleCDN.- SimpleCDN lets you
- #49 Not sure how you want to go with this part, if you want to cover each item individually like the others, or talk very briefly about each.Bullets randomly grabbed from notes...please change as you like.
- #50 - Here's the final resultwith our Apache serversending far-futureexpiry headers andgzipping html content.- To boost from a scoreof 90 - 99, I also broughtthe ShareThis module tothe 1.4 version, whichstopped it from beingincluded on every page.- Overall savings:212.7k - 99.96k page size5.7s - 1.7s page load timea
- #51 These are my inferences. Please add or change as appropriate.