High Performance Drupal meetup in Mar Vista on September 8, 2011

I'm not into second guessing the schedule of my colleagues. So, I'm fine with your choice, as Monday nights, I do D7 Book Study, weekly for the next 3+ months, and Pasadena Drupal UG (First Monday of the month).

I would rather focus on high performance for the next year or two, over a general meeting whose topics change over time. Why? I have been addressing Drupal performance tuning for the last 4 weeks, tweaking MySQL's my.cnf parameters. There is selecting the right hardware as well. More L1 and L2 cache, faster bus, to RAID, where RAM is not the whole story.

The few out of the box Performance Admin page checkboxes are well understood by me thanks to the D7 Book Study effort. Now, I have to learn everything in between, include the module design issues, like

blocks['new']['cache'] = DRUPAL_CACHE_CUSTOM;

or one of the other 5 possible values, and the Cache API functions like cache_set(), cache_get(), hook_flsuh_caches(), though module coding caching might be beyond the scope of your new meeting.

I've planned for the last 4 months to author a logical layer diagram for Drupal Performance/Caching, as I see over a dozen layers, from hardware to modules implementing content fields (CCK in D6, Fields and Entities in D7) and no diagram exists yet.

I'd like to add a 'rating' system indicating the easy fruit for a Drupal webmaster to set up, and low hanging performance gains with the least amount of installing difficulty and long term lack of tweaking as growth occurs, to what a high end Drupal server, with hundreds of sites on it, should use.

Addressing the range of end users will be key for the third diagram. End users will need to classify their use level of Drupal, from home computer, to shared hosting, to dedicated colo, to cloud computing. Each class has limitations on what caching methods are available to it. These limitations means the Drupal owner needs to focus their effort, and not find out this or that performance method is not available, after spending resources on learning those methods.

A fourth chart/table/wiki should supply them with an order of implementation for each method, to get the most bang for their time.

These documents will only summarize and direct new users to the low hanging fruit. They will have few details, though many URLs will point to where the details will be found.

That's this man's opinion, and I sticking to it.

So, Christefano, your new Performance Monthly Meeting is extremely timely for my career path and I am solidly behind assisting you in putting on the event, and making sure I get extreme value by the end of year.

I do request you contact the IE leaders and let them know, as it's best coming from you, and not from anyone else. That way, members can be sure the Southern California Drupal Community is coordinating growth, as best can be managed, given the rapid increase in Drupal popularity and demand for skilled craftspersons, that come from attending our meetups. Meeting dates are bound to collide now and then, though the coming decade. I just want to be sure organizers do all they can to avoid catching a fellow organizer unexpectedly, and the resulting hard feelings can be easily minimized with an email or phone call.

I'll be doing my best with posting minutes for your meeting, so those attending the IE meeting can still benefit. Plus, self interest means if I write the minutes in a way I can understand, then I will have revisited the presentation a second time with the writing effort, which reinforces my memory of all the facts, and will allow me to author a comprehensive set of overview diagrams that target a range of levels of Drupal usage.

So, self interest is ruling my direction. By the way, my host has over 20 Drupal sites on it, and tweaking MySQL decreased query time by 25%. Expectations are by the year's end the machine will be hosting over 100 Drupal sites.