Benchmarks don't mean a whole lot to me as they're all a bit on the subjective and software has gotten a little too complex to say "this is faster/better or more stable than this" because different situations highlight different things/needs. I mean Microsoft does benchmarks where they beat Oracle and have 99% uptime...haven't witnessed it myself though. I converted (mostly by removing all the "getRealPath") a legacy jserv application to tomcat, it did not use JSPs mind you. The site got ~150,000 hits a day. Tomcat kept up fine and was not noticably slower or faster, as far as the eye could see it was near-instantanious. (keep in mind I had no real bandwidth constraints when measuring this..those of you on old 56k modems probably don't know what that means) Later when rewriting in JSPs/beans/EJBs. Tomcat and Jboss were actually slower than the original application on initial startup but after about half an hour it was equal the speed if not faster. (but using perception its hard to say). I'd guess it was faster due to the number of apache connections open at once (dropped to ~35 from about 100). Some of this is due to the improvements in the application. I did have a number of performance problems with both editions of the application, but I traced them all back to the database (which had stack overflows and memory leaks) or the legacy application (which had synchronization problems). What other problems I had were usually either a configuration issue (documentation on both tomcat/jboss projects leaves much to be desired, I'd be happy to contribute to this effort at some point, however you have to know what the heck you're talking about well enough to explain it before you can document something or have greater than usual support for doing an un-sexy project like documentation from volunteers,in my humble opinion this is where the Suns and IBMs need to donate most...donate experienced tech writers and people who full time just analyze the stuff and document..that will win greater commercial support). So the bottom line is in my opinion Tomcat 3.21 has reached prime-time capability. If you're (somewhat off topic but related since they often get bundled) willing to load a "pre" then JBoss 2.1pre can be used, 2.0 isn't so ready due to various intermittant problems and the documentation which is confused between about 3 versions of it leaves so much to be desired...some effort is being made in changing this but they need to go through it with a fine tooth comb and say "still true/not true". Lastly although mod_jk is a royal pain to switch to, its worth doing. I had little luck getting the mod_jserv-tomcat-apache combination to work. (work means live more than an hour) Note that if you do uploads with Multi-part requests you'll need a direct-to-tomcat method of doing them as mod_jk breaks them. FYI: first edition was primarily servlet driven/interperated in-house tag language with jserv and apache. Second edition was the same except adapted for tomcat and mod_jk/apache Third edition was written in JSPs with some regular beans which front ended some EJBs. No servlets were used as this was a "view only" project and I'd intended to have a forth edition once I could redo the database schema. Equipment was a couple of load balanced Sparcs with another dual-processor sparc back end running Solaris 7. So anyhow thats my subjective evidence that tomcat 3.21 is ready for primetime while so many state otherwise. -Andy -----Original Message----- From: GOMEZ Henri To: [EMAIL PROTECTED] Sent: 3/3/01 6:54 PM Subject: RE: Some benchmarks >> I need to choose for my company the "next generation" servlet-engine. >> For now we are using JRUN. I am doing benchmark to choose >the next one. >> choices for me are : JRUN, RESIN... not Tomcat as it is >considered not >> stable >> and slow compare to the two others... When you say that Tomcat is slow could you give numbers. ie : tomcat served 1000 req/s and Resin 3000 req/s --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
