Here's a quick run-down:
...is doing a BOF on Project Workflow Management and Client Expectations.
Waterfall, Agile, Scrum, UML, Process Diagrams, Wireframes, Design Comps ... how does it all fit together into a clearly defined purpose?
...has a presentation on Advanced AHAH and Modifying Forms, which gets into that lovely UI goodness of dynamic forms generation, drag-and-drop, etc. He's also doing a presentation on Using SimpleTest to Prove Your Code. Very useful to any coder.
...has a presentation on Drupal Benchmarking and Performance, covering:
- Factors that affect performance
- Measuring performance
- Different types of hosting (Shared, VPS, "Grid", Mosso)
- Techniques used to make enterprise websites scalable (ie Facebook, LiveJournal)
- Basics of Performance-friendly Drupal Module development
...is presenting on RESTful services and Drupal, and will be showcasing his brand spanking new REST provider module which provides something of a REST API.
...is presenting on Contributing to Drupal, which is about how anyone can participate in the Drupal community. He is also presenting Drupal Lightning Demos:
Rapid-fire demonstrations of modules, themes, Drupal-powered sites, fancy Drupal code snippets and anything else Drupal related that can be demoed in 5-10 minutes. These are quick, 5-10 minutes including time for questions, demos of something you've built on or with Drupal. Unless we have very few demos there probably won't be time to go looking at code so just show how it works or what it looks like.
He's also doing a session on the Drupal Community:
I'd like to talk about the Drupal community, the ways in which we are open and sponsor participation and the ways we've push people away. Because we have pushed people away. What do we do that is right and what are we doing wrong?
There is also going to be a BOF about Making DrupalCamp Colorado better, led by Kevin Bridges and (hopefully) many other interested folks. Maybe we can pull together a DrupalCon proposal?
I was going to be joining Greg Knaddison in a session where we, as permanent members of the Drupal Association General Assembly, were going to give a little update on what's been happening and attempt to answer questions that may arise, but that proposal was rated lower than the others, so it's not going to happen. No, this is a weekend to get your geek on! See you there!
]]>Back during the Open Source CMS Conference (discussion on pingV.com) we attended a fundraiser/seminar hosted by Lullabot about Performance and Scalability. The presentation was really great. Some of it I knew already, some was new to me, but seeing it all presented together really helped solidify the concepts in my mind.
Shortly afterward we were engaged on a project that needed to really snap. The Make Earth Day Every Day project really needed their server to respond quickly. They also need it to handle large numbers of visitors - Earth Day was coming up! So, I put all my old and new performance tuning knowledge to work.
While most of these techniques apply to dedicated servers or VPS, some of the ideas are useful for shared hosts as well.
First, I used the Apache Benchmark tool to test out the servers and see how they would perform as a baseline. It's important to be methodical, do tests, make a small tweak, do more tests, and record the results along the way. You can't manage what you don't measure. With the default installation, the sites handled 5.5 requests per second. The Drupal cache wasn't enabled, so my first step was to do that. Immediately the performance went to 23 requests per second.
Using the vmstat diagnostic tools I learned about in the session I noticed that the CPUs on the web server were maxed out. So, I installed the APC opcode cache which drastically reduces the amount of processing and memory required for each page load. Without any further configuration requests per second went to 215.
Various other small tweaks (removing unnecessary Apache modules, and tweaks to the database configuration file) resulted in a gain of another 5 requests per second.
So, the final count is from 5 requests per second to over 220 requests per second. Given the nature of the site we expected users to spend a minute or more on each page which should allow for more than 13,000 simultaneous users.
There is much more valuable information in the output from the Apache Benchmark tool than just the requests per second, but it is an easy metric to use to help explain the magnitude of difference possible with some work in performance tuning.
I've talked mostly about the seminar at OSCMS2007 given by Lullabot and the slides are available online. But really there are lots of great articles on tuning from the Drupal community both in the Drupal.org Handbook and on various other sites like the 2bits.com book of Performance Tuning and Optimization for Large Sites.
Among all of these locations you can find lots of great information to help you tune your site for optimum performance.
]]>