Random Java performance podcast comments
By alexismp on janv. 19, 2009
I was recently listening to this JavaWorld podcast on Java scalability and was surprised to hear a few things (hopefully well paraphrased here) :
• "Java is not the best choice given its threading model and synchronizing". I just don't understand that statement. Still Java 5's concurrency API is still under-used by many IMO.
• "30 seconds GC pauses are common". Really? This sounds like 2000. Are you still seeing GC pauses above 10 seconds? There's now multiple GC algorithms to chose from and default options now provide really good performance in a large majority of setups.
• "Real-time Java is around the corner and will fix many latency issues". Real-time java is really not the issue to most web site scalability or latency issues. Maybe the garbage-first GC scheduled for Java 7 will be an easier answer than the current required JVM tuning.
• "ORM's are not needed, straight JDBC is better for scalability". I can't help but think that this can apply to only a handful of popular web sites. For everyone else, frameworks like JPA are just no-brainers.
• "More generally speaking, frameworks are bad for performance and scalability". I think some stack-traces can be indeed intimidating. Frameworks should strike a good balance between productivity and out-of-the-box performance. Tuning expertise for a given framework is usually a function of the popularity of that framework while some popular frameworks are known to have scalability issues.
• "Application servers are not a good idea because they mix business logic and web requests... a JVM should suffice". I am a strong believer in multi-tiered architectures and stateful applications so this sounds very wrong to me. The notion of a container is one of the most important break-through in recent years for productivity, transactions, persistence, and scalability. Clearly I don't buy or even really understand this assertion.
Performance and scalability objectives can justify to de-normalize the architecture (much like you would for database schemas) but while this podcast has value, I don't believe most developers should follow every recommandation in this podcast right off the bat.