Training: Drupal Security and Performance Tuning

Facilitated by Neil Drumm, MAPLight Developer, Drupal developer, api.drupal.org, drupal.org theme.

Neil will cover a range of advanced Drupal topics, including cache optimization, appropriate module configuration, intelligent module design and re-use.

• For admins and site builders: http://drupal.org/security/secure-configuration
• For developers: http://drupal.org/writing-secure-code
• For everyone: http://drupal.org/security-team

Performance: http://delocalizedham.com/drupal-performance-tuning

Notes:

Security stuff:

• Double check permissions and roles
• Double check input formats
• Turn off PHP input format
• Use filtered HTML and place new filtered tags
• Check out input format default modules
  • http://drupalmodules.com/module/input-format-manager
  • http://drupal.org/project/Modules/category/63
  • Also a good random input format tutorial: http://www.lullabot.com/articles/drupal_input_formats_and_filters
• Check out writing secure code page in Drupal handbook - http://drupal.org/writing-secure-code

Scalability stuff:

• Order of attacking scalability issues should be:
  • Fix the easy problems first
    • Make sure you are aggregating CSS and JS files, use cache
    • Pull views and panels out of db settings and into modules
      • Views caches in particular can get very big
    • Avoid sharing fields between content types
    • Rip CCK nodes out of CCK and make them custom modules
  • Buy some more hardware - separate the DB server, add additional web servers
  • Only then try to fix the hard problems

How to slow the harder scalability problems:

• When trying to cut load times, look at views and panels first
• Look for slow SQL queries using ySlow
• hackmysql.com has 2 good scripts to help pinpoint problems
  • mysqla
    • You can have this script explain a select statement and tell you why it is slow
  • mysql report
• OP code cache for PHP -> APC
• xdebug for profiling
  • xdebug gives backtraces on queries
  • can take a lot of memory to use
• devel module shows a list of slow queries
• More RAM on the web server can also help a lot
• Try reverse proxies such as varnish or squid
  • Could be useful for sites that have a lot of readers but not a huge amount of edits (read-only sites). This is the case with Wikipedia and CDAs "save their life"
  • This can help to avoid getting more hardware
  • These are generally hard to configure
• Consider using a content distribution network (CDNs).
  • These make JS, CSS, Images, and content files faster to download
  • Also hard to configure
  • Only really big sites need/use it
  • Advomatic uses Voxl
  • Drupal.org is going to try panther soon
• For testing you can use a load simulator
  • Don't do this on the same server as your live site (obviously)
  • Popular load simulators are Siege and Apache Bench