tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: Memory usage Tomcat 3.3 vs 5.5
Date Tue, 25 Apr 2006 23:12:55 GMT
Costin Manolache wrote:
> 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.
More power to such efforts as well.

I just see performance/scalability, management functionality, 
robustness, spec compliance, etc, as higher priorities.

If there is time and energy, I'd love see to all redundant MBeanInfo 
objects eliminated such that a single instance was used in all cases 
where the MBeanInfo is identical.  There certainly is no point to having 
such a see of small, long-lived, redundant data objects cluttering up 
the heap.

Jess Holle
> On 4/25/06, Jess Holle <> 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:
For additional commands, e-mail:

View raw message