Multi-tier architectures offer plenty of advantages, but easier tuning isn't one of them. Allan Edwards has written an article that discusses the problems of tuning in a multi-tier environment. Since the article is on the Oracle Technology Network, it focuses on the database side a lot. This is shown by the fact that the author thinks you should start tuning with the SQL.
"The vast majority of the applications that I see tend to have multi-tiered architectures, with J2EE running within the application server," says Edwards. "In this situation, transaction control and session control are often abstracted up, away from the database and application tiers sometimes with all sessions executing as the same Oracle user which has big implications for DBAs. It makes tuning much more complex than in a pure client/server environment. Furthermore, the application logic is being developed by Java specialists who generally have a shrinking appreciation for the database layer and related implications."
Read Taming Multi-Tier Tuning
Visit the home of the Middleware Architecture Series
What are your views on how to tune J2EE applications?
I just want to take issue with this statement;
"Furthermore, the application logic is being developed by Java specialists who generally have a shrinking appreciation for the database layer and related implications."
OK, I have met a lot of programmers who don't know diddly squat about good database design. Yes, it's true; I won't bore you with the details about a Visual Basic program our company used that I once had to review.
But it's definitely not all a one-way street. In fact far from it. I have also had to deal with many DBAs who know jack-all about how their customer (i.e. the application the programmers write) accesses their service layer. For example;
- insisting no programmer can have their own development schema where they have the rights to create and delete table structures. creating the deleting db tables are the sole right of dba staff even in the development database. (!!!)
- all answers to questions relating to database behaviour showing ignorance of the way an application accesses them. (e.g. no concept of O-R mapping tools).
- insisting on schema standards where postively everything is indexed with a numeric key, including common code tables, and where that key is never present in input data, and the code is NOT a first class entity of the domain. the program is forced to take the input data and discover the correct numeric key to use (i.e. with an extra database read or an extra table in a join). the reason? "performance". of just their layer not the application as a whole of course. and obviously they never heard the polemical statement from Knuth; "early optimization is the root of all evil"!!!
Sorry I just had to vent because this has been an issue for me recently.
Just to show I'm not being totally negative I did like this statement from the article;
Because of the many levels in multi-tier architectures, Edwards says, a common tuning mistake is to focus in on one level at a time and lose sight of the big picture. "You need to have a more general, holistic perspective, ..."
In fairness to the original author, the article seems to be specifically about how to tune a database to function well for a multi-tiered application, rather than multi-tier tuning in general.
When he says "Tune your SQL first", he is saying that you should do this before you attempt more elaborate database-related optimizations. I don't think he is saying that database tuning takes precedence over, say, tuning your Java code or your network architecture.
I think the main thrust of the article is that DBAs have to be more vigilant when maintaining a database for a multi-tier application, because pooled connections stay open basically forever, and you have to make sure that all your resources are properly released. That sounds like good advice to me.
As Paul quite rightly points out, it's very dba-centric, and from that perspective it's not a bad article at all. And it's certainly worth having a few tips for DB optimisation in your back pocket when tuning a multi-tier deployment.
Of course the issue is that there's *so* much more involved in tuning an entire system (unless you just want to solve one well-defined bottleneck) that simply could not be covered in Alan's 3000 words (yep, I counted), especially if that system is distributed across MOM, and all your components are written using different technologies, and there are a few legacy systems in the mix as we have here - and I am speaking from current (painful) experience.