tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Memory usage Tomcat 3.3 vs 5.5
Date Tue, 25 Apr 2006 22:46:15 GMT
I have to disagree with any statement like this - nobody can decide that his
use case is the 'main' use case for tomcat.

Yes, tomcat is used in a lot of production environments where speed
and manageability
are important. But it is also used by developers ( and I suspect for
each production site
you have few dozen developer instances ), it is used in IDEs like
eclipse/idea/etc.
Tomcat is also used to deploy large number of very small apps, or
small number of large apps, or small set of small apps :-)

Not sure what is the plan for commons-modeler, I think it is worth to
bring it back to tomcat or fork a separate implementation, not using
model mbeans and simplifying the model.
I think JMX is a great tool, and is essential to support it - but
there are ways to do it
without bloat, and it's a valid target for optimizations.

Costin

On 4/25/06, Jess Holle <jessh@ptc.com> wrote:
> Remy Maucherat wrote:
> > Abhi Karmos wrote:
> >> Has anybody looked in the code where the DescriptorSupport class is
> >> used? 22 thousand of these things is simply absurd. Nearly 100
> >> thousand DescriptorSupport.ValueHolder objects is even crazier. My
> >> guess is that the HashMap usage is related to the DescriptorSupport.
> > It is completely irrelevant compared to the memory usage of a single
> > "modern" web application, and at the same time it provides a useful
> > monitoring feature without being intrusive coding wise. Sure, we could
> > use standard MBeans, but the code would then be a mess. I don't
> > understand the point of bothering with this sort of stuff when there's
> > so little benefit.
> Despite my tone in my previous e-mail on this thread, I tend to agree
> with Remy that the Tomcat folk have bigger fish to fry.  An extra 10MB
> of overhead is not the top priority for most Tomcat users.
>
> Even without using standard MBeans I could certainly see dynamic MBeans
> with per-target-object-class caching eliminating most of this additional
> memory footprint.  Modeled MBeans are likely as capable of this as any
> other dynamic MBeans -- and if not that would be a reason not to use
> them in *future* projects.  [Commons "Dynamic" anyone?]
>
> All the same, the MBeans generally do what's needful in Tomcat and I'd
> thus hate to see any "cleanup" in this area take precendence over "real"
> stuff.
> > If you want the smallest web container in terms of memory usage or
> > size, I think you should not be using Tomcat. Tomcat is more geared
> > towards speed, GC friendliness and feature completeness than memory
> > usage.
> Agreed.
>
> I notice that many of the Tomcat MBeans actually provide fairly useful
> attribute and MBean descriptions.  I also notice a good number of MBeans
> with no MBean-level description, however.  Same for operations,
> operation parameter names and operation parameter descriptions.  Fixing
> this seems like a higher priority than introducing MBean
> descriptor/MBeanInfo sharing at this point.
>
> --
> Jess Holle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Mime
View raw message