Portal and WOW Pumpkin Carving

22 October 2009

It’s about that time to start thinking about what nerdy emblems can be carved into a pumpkin. Here are the past couple years of geek-o-lanterns my wife and I made:

GLaDOS
Portal’s GLaDOS survives as a Pumpkin.

For The Horde!
For The Horde!

Squirrel
Squirrelbot before pre-decompisition into a forsaken.

Murlocs-night
Trick-or-treat! ¬†Go ahead and reach in for some candy…if you don’t mind losing a hand to the murlocs. You can’t see them, but I also toothpicked some pumpkin slivers on their backs for spines.

Enterprise Over-Caching

22 October 2009

Caching your database tables within an app server for a website (eg. Memcached or C#’s Cache) is a very bad idea.

Every time you add caching to a set of data, you have to add extra code – which means added complexity and potential bugs. You’re adding consistency issues as well – especially if any other apps (or DBAs) can modify the data without invalidating the cache. These problems can be solved of course – with more code, which means even more complexity and bugs.

Most importantly, let’s consider speed. If you’re caching data, it’s probably because of speed concerns in the first place. One way or another, you’re going to need to access this data. Even worse, you probably need to sort the data too. Why the heck would you tiptoe around the database like you’re scared to pull data from it? That is exactly what the database is tuned for! Accessing the cache for these types of requests is significantly slower than pulling from an indexed database table.

Why not handle data access speed in your data layer? Rather than using each app server as a horribly inefficient slave database – use a slave database! This is going to be faster, more scalable, and require zero extra code.

Caching isn’t all bad, of course. Caching the static content of the 10 most popular articles that account for 70% of your website’s requests is probably a good idea. Caching your entire Users table? Not such a good idea. For some reason premature caching of entire database tables seems to be the norm in “enterprise” C# and Java web apps, even ones with a handful of users.

If you get put on a project like this, suggest scaling back the scope until it’s needed. Or at least until after the application is ready to be optimized based on performance profiling. Don’t add that code until there is justification that a performance problem exists, and that adding code is really the best way to solve it.