Wednesday July 07, 2004

I might be concerned with how easy a particular scaling solution is to integrate with the application language and framework, but they all can be made to scale. I prefer to look at how much the prevailing practices with the technology make change easy. Just 'cause you can prototype it quickly doesn't necessarily mean you can collaborate well with it and evolve it easily. And I've certainly seen my share of funky reinventions of the materialized view, half baked cache management systems and database pounders wind their ways into prototypes that become hacked architecture. So all of the hubbub about troutgirl's Friendster goes PHP post (and Rasmus' feeble attempt to indict J2EE) strikes me as trite (and perhaps I'm not the only one puzzled by it). troutgirl's remark that, "We had not one but TWO guys here who had written bestselling JSP books. Not that this necessarily means they're great Java devs, but I actually think our guys were as good as any team." Begs the question: what does that have to do with it? Were the performance problems really in the presentation tier? Or was the presentation so closely coupled to the backend that they couldn't be distinguished? And I need to know what reading not to recommend, what were the names of those books? Gimme a break.

Poor web application performance is often simply attributable to at least one of a handful of Common Stupid Mistakes:

1. Development shortcuts that are quick-n-dirty that also happen to introduce slow-n-dirty runtime characteristics (let's just call those "crappy hacks")
2. Insufficient use of caching or pre-generation of components that are static or have a low change rate (let's just call those "gratuitous dynamicism")
3. Inappropriate use of caching... does that logic need to be cached or is its invocation infrequent enough that maybe a plain old CGI is exactly how it should be implemented? (that'd be "gratuitous caching")
4. Excessive round-tripping to the database (well, that's just "excessive round-tripping")
5. Tight coupling of architectural pieces that have independent scaling and/or stability requirements... (score that: "tight coupling")
6. Nailing up resources i.e. does each child thread/process require its own database connection? (another potential effect of "tight coupling")

You can make those mistakes in any programming language and framework. The key for me is how easy is to avoid these traps given the practices that are widely used by adherents to a given application environment. How good are the tools? The test frameworks? Is clean object design and architectural layering widely appreciated by the development community around that technology?

There are lots of ways to make mod_perl and PHP or MySQL scale (Slashdot and Wikipedia will be happy to testify), there are lots of huge J2EE applications that have enjoyed terrific scaling, you might employ caching that is native to your technology (i.e. in Java, PHP or Perl) or agnostic caching. But regardless, if the architecture suffers from too many crappy hacks, gratuitous dynamicism, gratuitous caching, excessive round-tripping and tight coupling -- it's gonna suck. Period.

So concern yourself with how easy will it be to employ best practices, to evolve and extend the functionality over time and integrate with other applications. The scalability concerns can be handled with various means. ( Jul 07 2004, 11:04:57 PM PDT ) Permalink
Comments [1]