You are hereBlogs / Jeff Schuler's blog / Front/Back End Performance – Make Your Website Lightning Fast (DrupalCon DC 2009 notes)

Front/Back End Performance – Make Your Website Lightning Fast (DrupalCon DC 2009 notes)

Posted by Jeff Schuler - on 05 March 2009

Front/Back End Performance – Make Your Website Lightning Fast
Konstantin Käfer (Front End) and Khalid Baheyeldin (Back End)

Front End Performance

styles, scripts, images account for 80% of load time

background images, images, other media, html, css, scripts, other media...

over time:

Tools & Measurement

Measure: to prove optimization success

Overall load time?
Page size? Not a perfect metric: ping time, roundtrip time
Time until DOM is loaded?
Time until page is functional? : users perceive differently, or use different things

Tools

Most display as waterfall: Start, Connect, First Byte, Last Byte

How can we optimize?

Reduce requests (More requests more troublesome than larger files)
- CSS Sprites
  - many images into one file, and shift into view using background-position
- Aggregate scripts and styles
  - built into Drupal
  - Sophisticated: Support File Cache module
- Don't use redirects
Caching
Use CSS instead of images
- -moz-border-radius, -webkit-border-radius, border-radius
data: URLs in style sheets
Use a CDN
Caching
Gzip
CSS at the top
- Browsers don't render until all CSS has been loaded
scripts at the bottom
minify CSS and JS
remove comments and whitespace
- still savings, even with GZip
- Drupal's aggregator or sf_cache.module
Parallelization
- 2 requests per host name in parallel
- use multiple host names: higher parallelization
  - but don't overdo it: DNS lookups will slow down
- browser support for parallelization
reduce image weight
- OptiPNG, PNGCrush
  - Removes invisible content
  - Lossless recompression
- JPEGtran/ImageMagick
  - Remove color profiles, meta data, ...
  - Lossless
lazy initialization
microoptimization
- only if you have optimized everything else
  - "Premature optimization is the root of all evil." -- Knuth

Back-End Optimization

definitions

Define goals and objectives first

Optimization: diminishing returns

usually low-hanging fruit with dramatic performance; after that, it's more expensive and/or more difficult
infrastructure, patching Drupal, re-architecting the app

proper diagnosis is essential for any solution; otherwise, running blind
must be based on proper data, and analysis of the data collected

validate results on a test server

Physical server matters

Multiple servers

one DB server, multiple web servers
Can use DNS round robin for load leveling, or proper load balancers (commercial / free,) or even a reverse proxy
- only if you have the budget
- complexity is expensive -- running cost
- tuning a system can avoid or delay the split

LAMP Stack

Linux

Use a stable distro: Debian stable, Ubuntu Server LTS, CentOS)
Use recent versions
Use whatever distro your staff has expertise in
Be a minimalist; avoid bloat
- Install only what you need
Balance: "compile your own" vs. upgrades
Compile your own:
- pros: full control on specific versions
- cons: not easy to do security upgrades
Apache
- mod_php and mod_rewrite only, from the start
- MaxClients:
  - too low: can't serve a spike
  - too high: mem can't keep up with load & start swapping
- MaxRequestsPerChild
  - to terminate process faster and free up memory
- KeepAlive
  - should be low: ~3 seconds
- mod_gzip/deflate
lighthttp (lighty)
- popular with RonR crowd
- 1MB per process
reports of bad mem leaks, recently
nginx
- newcomer
- more stable than lighty

MySQL

MyIsm
- faster for reads, less overhead, poor concurrency
innoDB
- transactional, slower in certain cases (SELECT COUNT(*))
- Better concurrency: good for heavily hit tables, such as sessinos, watchdog, ..\
Tuning
- Query Cache (most important)
- Table Cache
- Key buffer
- InnoDB for sessions, watchdog, accesslog
- Temp tables on Linux tempfs (in memory)
Replication
- patch needed until Drupal 7

PHP

Always use recent version: 5.2 min for 7.x and many 6.x contribs
Install an Op-code cache
- eAccelerator (fastest), APC (most stable)
- Benefits
  - Dramatic speedup of apps,
  - decrease in CPU/mem utilization
- Won't help for
  - not just code execution
  - network connections
  - sorting of arrays
  - heavy database access
  - tagadelic, node access modules, admin_menu, forum, tracker
mod_php
- normal apache config
- shared nothing
- no state retained between requests, less issues, most tested/supported
- stay with mod_php if possible
php as CGI
FCGI
- use if possible
other exotic ways...

Drupal

db intensive
disable modules you don't need
make sure cron runs regularly
enable throttle
- be wary about throttle and cache
does your module do stuff over the network?
- cache the data, and use job_queue or queue_mail_module
Drupal Caching
- anonymous only
- enable page caching: expire too often on a busy site, causing slow-downs
- set expiry
Boost for anonymous visits
Pluggable caching -- custom caching
Block caching -- core in D6
memcached
- necessity for every big site
- distributed object caching in memory
- no disk I/O (database or files)
- requires patches...
Advanced Cache Module
Slow modules
- Statistics module
  - adds more queries
  - disable popular content block
- Aggregateor2 abandoned, thank god
- Tagadelic
- Admin_menu (adds up to 500ms)
- Node access modules with large number of nodes (10,000 nodes)