It's impossible to predict the performance of an app except as an approximation based on what it's trying to do. Every app has its own characteristics, and webapps are no different. While there are certain obvious good and bad things to do, the real bottlenecks are never when they're expected to be, so the ultimate determination has to be made by measuring under load. Just doing tricks with low-level code or library organizations or stuff like that in the expectation of better performance costs more than it's worth - especially when the tricks involve undermining the maintainability or integrity of the app. In fact, code tricks can actually make it HARDER to optimize, because they can cause the code to be much harder to unravel before trying an alternative. And, in point of fact, given a choice between a better algorithm and "optimized" code, go with the algorithm. Just make sure that the algorithm in question is really "better" for that particular task. I had one famous case where a bubble sort would vastly out-perform heap/quicksorts, because the data was coming in in a worst-case sequence for those sorts.
As long as each WAR contains its own copy of a JAR, there's no problem. Only when you start sharing the same file among multiple apps is there risk. However some jars ARE intended to be shared - such as the
JDBC driver jars - and they
should go into the tomcat common library directory.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
