Linux

Here at Four Kitchens we make BIG websites — a lot of them. In the past, keeping up with the development environments for all of these sites added a lot of overhead, which ultimately means more time managing code than writing it. So like good developers we asked ourselves: “how can we make this better, lower maintenance, and reusable?” What we came up with isn’t necessarily anything new, but has completely changed how our internal development process works.

Anyone experienced with high-performance, scalable PHP development is familiar with APC and memcached. But used alone, they each have serious limitations:

APC

• Advantages
  • Low latency
  • No need to serialize/unserialize items
  • Scales perfectly with more web servers
• Disadvantages
  • No enforced consistency across multiple web servers
  • Cache is not shared; each web server must generate each item

memcached

• Advantages
  • Consistent across multiple web servers
  • Cache is shared across all web servers; items only need to be generated once
• Disadvantages
  • High latency
  • Requires serializing/unserializing items
  • Easily shards data across multiple web servers, but is still a big, shared cache

Combining the two

Traditionally, application developers simply think about consistency needs. If consistency is unnecessary (or the scope of the application is one web server), APC is great. Otherwise, memcached is the choice. There is, however, a third, hybrid option: use memcached as a coordination system for invalidation with APC as the main item cache. This functions as a loose L1/L2 cache structure. To borrow terminology from multimaster replication systems, memcached stores “tombstone” records.

I downloaded and installed OpenSolaris to experiment with its LAMP stack implementation. I eventually want to set up a headless, SSH-accessible box I can use to experiment with unique OpenSolaris features like dtrace on PHP and MySQL.

UPDATE 2009-06-08: You can download these slide decks (and more!) from our Presentations page.
—The Web Chefs

DrupalCamp Stockholm 2009

• Is Drupal secure: the Drupal project’s responses to the web’s most common software vulnerabilities
• Scalable Drupal infrastructure: a guide to planning, deploying, and scaling big websites

Drupalcon DC 2009

• Building infrastructure you can scale, monitor, and maintain
• The next 10 Years: the future of application scalability and responsiveness

Fresh packages, 64-bit only this time. I can make 32-bit ones if anyone would like some.

• Bazaar x86_64
• Bazaar SRPM
• BzrTools x86_64
• BzrTools SRPM

For me, my projects are code-based and, hence, mostly a collection of version-controlled branches. So, my “Projects” directory (located at ~/Projects) contains a smattering of branches organized into multi-level directory structures.

In my last post, I noted that shared branch storage is the key to fast branching, good offline access, and efficient disk usage. I even covered a quick way to get it rolling for Drupal branches. But it’s one thing to know how and another to know “best practices,” so I’ll share how I do things.