I'll just add one more tidbit into the conversation. The biggest bottleneck in most dynamic sites is the data access layer. In the benchmarks I ran recently, getting 16-20K of data from oracle will take a minimum of 200ms.
when you compare this to the time tomcat spends doing other work, it becomes obvious that more than 50% of the CPU time is getting data. The only situation where page markup is slow is using XML with complex schema. Most of this stuff is covered in the book with an example webapp and benchmarks to show the trade off in performance. peter lin --- Will Hartung <[EMAIL PROTECTED]> wrote: > > From: "Turner, John" <[EMAIL PROTECTED]> > > Sent: Thursday, February 06, 2003 10:01 AM > > Subject: RE: Tomcat Performance Concerns > > > > 1. Orion is a "competitor" to Tomcat making > benchmarks from them > > automatically suspect (at the very least > biased)...that URL is 2 years > > old...massive changes have been made to Tomcat > since > > I'm with John on this one. Not to slight Orion, but > everyone knows > benchmarks are meaningless, unless they're YOUR > benchmarks. > > But think very hard about your statement here. Think > about what the issue > is. > > Here you have an application that you are thinking > of or have already > written. You write it to the best within your > abilities and you FOLLOW THE > PLATFORM SPEC. > > Now, it comes down to deployment, tweaking, and > performance. > > So, you take your application and you benchmark it > using whatever tools you > are willing write/buy/download. > > If your application provides you with acceptable > performance, you're done. > > But here's the real treat. If it's NOT, then drop it > on any of several > containers (Orion, Resin, Tomcat, Jetty, Sun ONE, > JRun, Weblogic, Oracle, > IBM...and I'm missing some). > > Now benchmark it again...is it better? Is it worse? > > Do that a couple of times and stand back and bask in > the glow when it > hits...had you developed your application in > ANYTHING else, this would not > be an option. If you wrote your app using any other > technology, PHP, Perl, > ASP, .NET, WebObjects, Zope, etc. then when your > application was finished > and you wanted to deploy it only to discover you > were unhappy, you find you > had no recourse. > > With any other methodology you would need to look > for more hardware or > clustering or rewriting. All of those can be > expensive and complicated (and > I'm not saying the having to buy licenses for some > of these other containers > will not be expensive, as they can be). > > This is the real power of what Tomcat has to offer. > If it doesn't meet your > production needs, then something else might, and you > have the flexibility to > choose that option. You can say "Tomcat sucks, > forget it, I'm leaving" and > move on. > > The portability of WebApps is getting better with > every release of the > specification and the containers. This is why if you > follow my posts here, I > almost always bring up portability because I think > that it's extermely > important and fundamental to the platform, it's why > I like that Tomcat is > the reference implementation so that I can be better > assured that were > striving to compliance with the spec. > > Now, of course, the spec is vague enough and has > gray areas that can make > porting difficult, and I wish Tomcat were a bit more > strict on things, but > portability is real, it's possible, and it can be > less painful than you > think. And I think we all should send a big Thank > You to the Tomcat team, > Sun and the spec writers for pushing this effort > forward, and tell the > platform providers that portability is a real > concern to us as developers. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
