Parallel programming
Sequential programming is one of those things that is nice for controlled examples, but is starting to look awfully impractical in the real world. In fact, we’ve had some discussions at StyleFeeder lately where we were talking about the things that we as a company could not exist without. Open source software is one, for example. Sharding is another. Concurrent programming was also on the list. And I don’t think that this is the result of a failure of imagination on our part, either: we really couldn’t exist without this stuff.
On almost any page on StyleFeeder, there are a few threads at work doing things like data retrieval from multiple data sources, recordkeeping, updating caches, putting messages on queues and the like. We’ve made some wonderful little constructs for making this kind of work easy, the heart of which is a little component called Assembler.
You give Assembler a few FutureTasks and a timeout. Like, “go and do these four things and just stop doing whatever you’re doing after 1000ms since it’ll be too late at that point”. In addition to helping keep the application profile level when we are under load, it also dramatically speeds up the page load time.
Of course, we also rely heavily on Whirlycache and various message queues, too. Both of those provide other benefits, but a solid understanding of concurrency is necessary in order to understand when you are seeing a problem and how to diagnose it. Because, yes, we somtimes see funny race conditions that are really hard to reproduce. In practice, you frequently have to be able to look at code and analyze execution paths to understand where things could possibly go wrong.
Experience with those skills is something that we all have – again, out of necessity. Because I’m pretty sure that StyleFeeder can’t exist without threading at this point. I’m eagerly watching Dan Milstein’s notes over at Lookery with his Erlang adventures. Concurrency, indeed.