Today’s subject is anonymous sessions. Frameworks (and developers) love them because they are simple and convenient, but it comes at a cost. Keeping track of sessions for every visitor on a high traffic site is far too expensive to be practical. Developers should know how to work around this, but their frameworks need to support them.

The first framework on my mind is Drupal. I filed an issue last year that Drupal should support disabling anonymous sessions. It’s still unassigned so I’m guessing it’s not a high priority, but it was one of the main things that made me choose not to use Drupal on mozilla.com. I wrote some ideas on how to handle it and got some responses from people suffering the same fate. No word on any progress though.

The second framework, CakePHP, has an AUTO_SESSION variable that, just like $cacheQueries, is far to easy to misplace faith in.

By setting AUTO_SESSION to false, you can’t read or write to the session. Working as advertised? Not so much. If you take a closer look at what’s actually happening you’ll see that the session is still getting started, it’s just that CakePHP is blocking your access to it. Even with AUTO_SESSION off, a cookie with a unique ID is set, and a row is still inserted into the sessions table. That last part almost brought down AMO last night. I wrote a patch that disables anonymous sessions for real, but anyone that has talked to me about patching core code knows I don’t like to do it.

When you’re writing code, framework or not, don’t forget about scalability.

Over the past couple of days I’ve felt a growing confusion about how the web infrastructure works on www.mozilla.com. People are beginning to use Kubla (it’s started with a small set and is steadily growing), and they’re asking some good questions that hopefully I can help answer here:

Firstly, I think everyone with access has already seen this diagram, but bear with me:

Fresh changes are committed to the first (top) tier – also referred to as “trunk”. If you’re making the change yourself you’re actually affecting this tier. You can preview any of the changes from the first tier on www-trunk.stage.mozilla.com.

The second tier (also known as “stage” or “staging”) is where changes are previewed before they are pushed live. When something is pushed from trunk to stage it will be on this second tier and viewable at www.stage.mozilla.com. To get to this tier, a change needs to be approved by a human (a publisher in Kubla). If you have access and you want to see the differences between trunk and staging, look at the staging queue.

The final tier is our live site (or “production”). Anything pushed on to this tier will be on www.mozilla.com within an hour, automatically. To get to this tier, a change needs to be approved by an admin in Kubla. The differences between the staging site and the live site can be seen in the production queue.

One of the main things to remember is that changes are not instantaneous. Moving a change from trunk to stage and stage to production both require human interaction. The staging site and the production site are updated periodically (Kubla shows an estimated time to next update on the left hand menu when you log in). For production particularly, this is definitely an estimate. The updates still need to rsync to our servers and then the aggressive caching in front of them needs to expire. Generally that’s an additional 15 minutes.

For changes that need to go out together or at a specific time we can speed up some of this process, but it becomes less automatic the faster we want it to go. For most updates the automatic systems should work fine. As always, I’m happy to answer questions if you have them, either about this process or Kubla itself.

This was my first time attending one of their meetings, but I think the turn out was impressive for such an informal get-together (I’m guessing around thirty people showed up). There were several newcomers to Drupal that were just wondering what the buzz was about and how it could make their lives easier. After some introductions, the talk flowed mainly around nodes vs. pages, views and CCK. I think a lot of people got their questions answered and got a jump start on their projects.

On the multilingual side of things, I was not so fortunate. By the end of the night, I didn’t find anyone who was already using Drupal in more than one language. A couple people mentioned waiting for Drupal 6 with it’s pile of i18n additions, but that’s not really an option at this point since I need to get something up and working. So, my plan is still to stride boldly forward, armed with a list of modules people mentioned (I’ll post more on that once I have a chance to use them), and my newfound friend.

After the meeting was over, I lost track of time while meeting people and sharing ideas. Eventually our conversations migrated into the parking lot, and we decided we should all go home and sleep before the sun started rising again.

Overall it was definitely worth going – I didn’t learn what I went for, but I got some good ideas (not just about Drupal!) and met a bunch of new people. If you’re in the area and have an interest in Drupal, it’s a great place to meet others and see what kinds of things they’re doing with it in the real world. Thanks to Sam Keen for organizing and the bus project for providing the meeting space.