On the first edition of The Knife Block, Dustin shares his tools of the trade, from hardware to software, and even music recommendations.
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:
- Low latency
- No need to serialize/unserialize items
- Scales perfectly with more web servers
- No enforced consistency across multiple web servers
- Cache is not shared; each web server must generate each item
- Consistent across multiple web servers
- Cache is shared across all web servers; items only need to be generated once
- 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.
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
On December 2, 2008, customers of SonicWALL woke up to broken firewalls. This wasn’t the result of a real problem in the firewalls; it was a result of SonicWALL’s DRM server malfunctioning and deactivating all customer firewalls.
The relationship between customers and vendors of proprietary software is fundamentally adversarial: proprietary vendors have business models where customer activity (like installing Windows on a desktop) requires payment to the vendor. Because the activity happens entirely on the customer side and paying the vendor conflicts with the customer’s desire to save money, proprietary software vendors don’t trust their customers to pay them.
Nodes have evolved remarkably over Drupal’s history. In Drupal 4.7, node types were typically created by modules that “owned” their node types. There was no way to create a node type without a module behind it. Modules creating node types would implement hook_node_info() and directly handle the the main loading, saving, and editing of the node type. Drupal core handled the loading and saving of the title and body. Modules doing this were effectively subclassing a pseudo-abstract node class (a class containing title and body only) in core and adding their own fields.