On 12/22/05, Henri Gomez <[EMAIL PROTECTED]> wrote: > 2005/12/22, Remy Maucherat <[EMAIL PROTECTED]>: > > Henri Gomez wrote: > > > Well a Tomcat will a small memory footprint is also very interesting for > > > me :) > > > > How is Tomcat memory usage large ? Personally, I would think it's > > extremely reasonable given the feature set, at least when using APR. It > > would seem the base Java runtime would completely offset any gain there. > > Well memory is not the only point, faster start and less class to be > loaded is also very important for me. In my company we're still using > Tomcat 3.3.2 on our production servers (iSeries) since they are quite > fast to start and that's very important when you have at the same time > not less than 20 or 25 instances of Tomcat starting in its own JVM > (one tomcat for a customer since the applications hosted have > differents life cycle and constraint). >
I didn't do any real benchmark, but the single-jar 5.5 should be as fast on startup as 3.3. Less class loaded - and less classes/features you need to worry when setting up and maintainig is what I meant by footprint - Jetty is around 0.5M I think. The fact that we have features for everyone is nice - but a developer doesn't need clustering or APR, and a production server doesn't need the old connector, the simple realm or the even the jasper compiler. It's more about beeing simpler for everyone - by providing the functionality they use. And no - it doesn't require any major refactoring - just small tweakings. I understand this doesn't help for JBoss - but tomcat != jboss. As for JMX - I think we do have a lot of things exposed, and adding more is quite easy. I think part of the problem is that we may have too much :-), and most generic JMX tools are not that good when you have too much data to browse. IMO organizaing a bit the information and maybe providing simpler interfaces would help. Having a minimal set of features in the base package doesn't mean you can't have a lot of features, and it doesn't mean it's much harder to add features. In a production environment it's the same - either you remove all the components you don't need or don't understand ( and might break something ), or just add the components that you need. Think about Firefox versus Mozilla. We are in exactly the same situation, just on server side :-) It's funny that JBoss does have most of this capability already - so I understand Remy not wanting to reinvent the wheel :-), but I don't think he can deny that this is a good thing to have. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]