Bug 63237 - Consider processing mbeans-descriptors.xml at compile time
Summary: Consider processing mbeans-descriptors.xml at compile time
Status: NEW
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.16
Hardware: PC Mac OS X 10.1
: P2 enhancement (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-06 01:14 UTC by Phillip Webb
Modified: 2019-05-15 13:38 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip Webb 2019-03-06 01:14:35 UTC
Tomcat currently parses `mbeans-descriptors.xml` files when it first starts to build MBean information. If MBeans could be created directly, rather than by parsing XML then startup time could be improved. This is particularly relevant when using an embedded Tomcat with a serverless architecture.

One possible solution might be to parse the XML files during the build process and generate source code that directly creates the required objects. This would save needing to read and parse XML during startup.
Comment 1 Remy Maucherat 2019-03-06 09:01:59 UTC
I have not tried to measure the time and resource costs of this parsing. Obviously changing it to something compiled would not be exclusively beneficial, so there needs to be clear gains for the embedded use case.
Comment 2 Phillip Webb 2019-03-06 19:15:38 UTC
@Remy

> I have not tried to measure the time and resource costs of this parsing

The only evidence I have currently are profiling results that appear to indicate the SAX parser taking a chunk of time during startup. I imagine for most standalone Tomcat users, this isn't really an issue. For users of embedded Tomcat, these little optimizations can really help.

Anecdotally, I have implemented similar performance tweaks previously by replacing logback XML parsing with programmatic configuration [1].

[1] https://github.com/spring-projects/spring-boot/issues/1796
Comment 3 Remy Maucherat 2019-03-06 19:47:17 UTC
Profilers often exaggerate the impact of some operations, so this has to be taken with an amount of caution. XML parsing is expensive for sure, but the descriptors are not too huge and MBeanUtils.createRegistry takes 83ms on my computer, which is not exactly the end of the world.

The solution proposed [generating mbeans code :( ] is a bit annoying to say the least compared to the descriptors. On the plus side, I'm pretty sure regular mbeans perform better at runtime than model mbeans, this is not so innocent when cloud monitoring goes crazy and uses 100s of metrics.
Comment 4 Phillip Webb 2019-03-06 20:15:58 UTC
> MBeanUtils.createRegistry takes 83ms on my computer, which is not exactly the end of the world

That's a really interesting metric and quite a significant amount if we're talking about using embedded Tomcat in a serverless environment where runs are very short lived.

> The solution proposed ... is a bit annoying to say the least compared to the descriptors

OK. I probably should have just stated the problem and not suggested a solution. I'm not too keen on generating code either.

Let me rephrase. Would a (potentially hand crafted) code based alternative to `mbeans-descriptors.xml` be something you'd consider worthwhile?
Comment 5 Phillip Webb 2019-04-08 23:03:20 UTC
I've got an experimental branch[1] that replaces the XML files with registrar classes.

So far the results aren't particularly inspiring and I'm not seeing a big improvement in performance. I think the main reason is that the lambda based approach that I adopted has quite a bit of overhead itself.

I hacked together a small bit of code to migrate the XML[2], so it might be worth having another go if we can come up with an approach that doesn't use lambdas. So far, I've not been able to think of an API without them that would be quite as nice.


[1] https://github.com/philwebb/tomcat/tree/bz-63237
[2] https://gist.github.com/philwebb/79d3dc5446f0c4a050115b05918eeee1
Comment 6 Konstantin Kolinko 2019-04-09 08:25:55 UTC
(In reply to Phillip Webb from comment #4)
> That's a really interesting metric and quite a significant amount if we're
> talking about using embedded Tomcat in a serverless environment where runs
> are very short lived.

1. I guess that in your use case of short-lived Tomcats (or whatever those "serverless" environment is) you do not need JMX support at all. (And thus no need to really parse these files).


2. The topic of JMX was also mentioned in thread "Becoming graalvm friendly?" on dev#.

https://tomcat.markmail.org/thread/kayfacujrpt2diht
Comment 7 Mark Thomas 2019-05-15 13:38:21 UTC
Has the ability to disable JMX made this enhancement request obsolete?