Re: What is a reasonable performance degradation?

[Mark Thomas]

On 30/04/2025 14:59, Doug Whitfield wrote:

Hi folks,

This feature was added in 9.0.90:
The system property org.apache.catalina.connector.RECYCLE_FACADES will now 
default to true if not specified, which will in turn set the default value for 
the discardFacades connector attribute, thus causing facade objects to be 
discarded by default. (remm)

It makes sense that would cause some performance degradation. We are currently 
seeing *at least* a 5x increase in the number of connections. This doesn’t 
*seem* right, but maybe it is?


That does seem high. Are requests/second staying the same? That would 
suggest each one is taking 5x longer.



We’ve been able to reproduce this in 9.0.90 through 9.0.104. If we set 
RECYCLE_FACADES to false, then we get the performance we have come to expect.

I am trying to get some additional information from the performance team to see 
what exactly they are doing. Perhaps something needs to be updated in their 
code, but in the meantime wondering what others have seen and what folks think 
is a reasonable degradation.


Let me run some tests and I should be able to give you a reasonable 
upper bound.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

What is a reasonable performance degradation?

[Doug Whitfield]

Hi folks,

This feature was added in 9.0.90:
The system property org.apache.catalina.connector.RECYCLE_FACADES will now 
default to true if not specified, which will in turn set the default value for 
the discardFacades connector attribute, thus causing facade objects to be 
discarded by default. (remm)

It makes sense that would cause some performance degradation. We are currently 
seeing *at least* a 5x increase in the number of connections. This doesn’t 
*seem* right, but maybe it is?

We’ve been able to reproduce this in 9.0.90 through 9.0.104. If we set 
RECYCLE_FACADES to false, then we get the performance we have come to expect.

I am trying to get some additional information from the performance team to see 
what exactly they are doing. Perhaps something needs to be updated in their 
code, but in the meantime wondering what others have seen and what folks think 
is a reasonable degradation.

Best Regards,
Douglas Whitfield | Enterprise Architect



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: What is a reasonable performance degradation?

[Mark Thomas]

On 30/04/2025 16:17, Mark Thomas wrote:

On 30/04/2025 14:59, Doug Whitfield wrote:

Hi folks,

This feature was added in 9.0.90:
The system property org.apache.catalina.connector.RECYCLE_FACADES will 
now default to true if not specified, which will in turn set the 
default value for the discardFacades connector attribute, thus causing 
facade objects to be discarded by default. (remm)


It makes sense that would cause some performance degradation. We are 
currently seeing *at least* a 5x increase in the number of 
connections. This doesn’t *seem* right, but maybe it is?


That does seem high. Are requests/second staying the same? That would 
suggest each one is taking 5x longer.


We’ve been able to reproduce this in 9.0.90 through 9.0.104. If we set 
RECYCLE_FACADES to false, then we get the performance we have come to 
expect.


I am trying to get some additional information from the performance 
team to see what exactly they are doing. Perhaps something needs to be 
updated in their code, but in the meantime wondering what others have 
seen and what folks think is a reasonable degradation.


Let me run some tests and I should be able to give you a reasonable 
upper bound.


I see about a 2% difference for a trivial Hello World servlet. That 
should be the upper bound as most requests will be more complex and take 
longer (hence the fixed difference cause by Tomcat should be a smaller 
percentage of the overall request time).


If you are seeing a 5x difference then I'd suggest it is time to start 
up your favourite Java profiler and see what is going on.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: What is a reasonable performance degradation?

[Rainer Jung]

Am 30.04.25 um 15:59 schrieb Doug Whitfield:

Hi folks,

This feature was added in 9.0.90:
The system property org.apache.catalina.connector.RECYCLE_FACADES will now 
default to true if not specified, which will in turn set the default value for 
the discardFacades connector attribute, thus causing facade objects to be 
discarded by default. (remm)

It makes sense that would cause some performance degradation. We are currently 
seeing *at least* a 5x increase in the number of connections. This doesn’t 
*seem* right, but maybe it is?

We’ve been able to reproduce this in 9.0.90 through 9.0.104. If we set 
RECYCLE_FACADES to false, then we get the performance we have come to expect.

I am trying to get some additional information from the performance team to see 
what exactly they are doing. Perhaps something needs to be updated in their 
code, but in the meantime wondering what others have seen and what folks think 
is a reasonable degradation.


Maybe your environment was already experiencing a high memory/GC 
pressure from object allocation. Then the additional allocations needed 
due to throwing away the objects instead of reusing them cloud have 
pushed the JVM over the border.


Performance bottlenecks often show non-linear behavior. As long as you 
stay away from the bottleneck you wont observe it, when you get close to 
it and above, it kills your throughput.


So when doing profiling etc. also check your for GC behavior and GC 
logs. Analyzing apps for performance problems while in fact you have a 
GC problem often feels like looking for an automotive engine problem 
while in fact you have your hand brakes put on.


Just a rough guess though.

Best regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: global web.xml question

[A Name]

On Tue, Apr 29, 2025 at 1:07 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> > ABT,
> >
> > On 4/29/25 11:25 AM, A Name wrote:
> > > On Tue, Apr 29, 2025 at 10:54 AM Christopher Schultz <
> > > ch...@christopherschultz.net> wrote:
> > >>> Are you able to view the sources of the application? Are you (or your
> > >>> team) knowledgeable enough about the code to make such changes?
> IMHO, I
> > >>> would take the time to make these changes because it will simplify
> your
> > >>> application (Tomcat would now be responsible for building and
> managing
> > >>> the data source) and also allow you to configure your application in
> a
> > >>> more flexible way -- essentially it makes it possible to achieve your
> > >>> goal of decoupling the configuration from the application bundle
> itself.
> > >>
> > > I have a team of developers - but, at this moment, the customer does
> not
> > > want a path that includes code changes.  We may change in the future,
> but I
> > > was investigating a no-code change option.
> > >
> > >
> >  In the new world, I'd need 2 sets of those parameters (basically
> with the
> >  same names for the app to find them).  one pointing to
> dbserver-site1 and
> >  one pointing to dbserver-site2.
> 
> >  Basically I'm looking for ideas that would not involve App code
> changes if
> >  possible.  I can change the XML configs in the conf directory
> without
> >  issue... but for program reasons, at this time, the app code (or the
> >  META-INF/xml files) are not supposed to be touched on considering
> this
> >  adventure.
> > >>>
> > >>> An app code change would be best, but you can also use some well-work
> > >>> hacks to get around that.
> > >>
> > >> We can keep that in mind for the future - but due to other priorities
> from
> > > the customer, code changes for this are not on the table.
> > >
> > >
> > >>> I think your host/site context.xml file ideas are interesting.
> Would I be
> > >>> able to take the context info that I put here out of web.xml and put
> it in
> > >>> the conf/Catalina/localhost/site1app.xml and put another copy in
> > >>> conf/Catalina/localhost/site2app.xml with the different
> > >>> url/username/password?
> > >>>
> > >>> That would be an ideal and simple answer.
> > >>>
> > >>> I can think of two other ways to do this. The first way requires no
> code
> > >>> changes and should continue to work. It essentially uses the same
> > >>> servlet context parameters you are already using, but re-locates
> them to
> > >>> context.xml -- which I didn't actually know you could do until I just
> > >>> re-re-re-re-read the documentation.
> > >>>
> > >>>
> > >>
> https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Context_Parameters
> > >> <
> https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Context_Parameters
> >
> > >>>
> > >>> You can remove these from WEB-INF/web.xml:
> > >>> 
> > >>>   foo
> > >>> bar
> > >>> 
> > >>>
> > >>>
> > >>> And put them into META-INF/context.xml under  (which is the
> > >>> document-element for that file) :
> > >>>
> > >>> 
> > >>>
> > >>> If you move those definitions and they work, then you can take the
> next
> > >>> step and move the application's META-INF/context.xml file out of the
> > >>> application and into Tomcat's conf/[engine]/[host]/[appname].xml
> > >>>
> > >>> If that works, then enjoy your day. :)
> > >>
> > > I might put them straight in the appname.xml in my sandbox - changing
> > > META-INF/context.xml changes what deploys with the app and that's
> still in
> > > the "not right now" currently.
> >
> > Tomcat does not read both META-INF/context.xml and also
> > conf/[engine]/[host]/[appname].xml and merge them together: the latter
> > takes precedence. So you'll have to merge them yourself. Just copy the
> > existing META-INF/context.xml file -> conf/[engine]/[host]/[appname].xml
> > and modify from there.
> >
> > -chris
>

Thanks Chris & Mark!

I'll take note.  I sandboxed this yesterday afternoon just putting those
database context-params into an appsite1.xml and  appsite2.xml and it
worked.  I'll doublecheck the META-INF\context.xml entries as well to make
sure I didn't lose anything in the test.

Re: When was the first stable GA release of Apache Tomcat 11.0.x?

[Mark Thomas]

Minor nit:

Tomcat also supports:

Jakarta Annotations
Jakarta Debugging Support for Other Languages

but we don't list then on the spec age. We probably should.

Mark


On 29/04/2025 15:36, William Crowell wrote:

Chris,

Beautiful answer and exactly what I was looking for.  Thank you.

Regards,

William Crowell

From: Christopher Schultz 
Date: Tuesday, April 29, 2025 at 10:32 AM
To: Tomcat Users List , William Crowell 

Subject: Re: When was the first stable GA release of Apache Tomcat 11.0.x?
William,

On 4/29/25 7:04 AM, William Crowell wrote:

Just for my clarification: When was the first stable GA release of
Apache Tomcat 11.0.x?

I believe it was October 9th, 2024, but I did see the Jakarta EE
Platform Web Profile 11 was released on March 30th, 2025:

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojects.eclipse.org%2Fprojects%2Fee4j.jakartaee-platform%2F&data=05%7C02%7CWCrowell%40perforce.com%7C4ab64e9c638441fcaf1708dd872a988b%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638815339204486239%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zlCnnqRASMH70HWufc9WqhuyPR1ZO5eEm0P8TUMXe%2F0%3D&reserved=0
releases/web-profile-11

I think that Tomcat 11.0.0 was released earlier than the Jakarta EE
Platform Web Profile 11 because there were no further changes to the
spec.  They just had to get one implementation to pass the TCK
(Glassfish) which happened last month.  Am I correct?


https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-11.0-doc%2Fchangelog.html%23Tomcat_11.0.0_&data=05%7C02%7CWCrowell%40perforce.com%7C4ab64e9c638441fcaf1708dd872a988b%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638815339204505883%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eLzGbDb22sAifpJctHfO655ehgOyTPDm3qHteEnV7Bc%3D&reserved=0(markt)

The releases before 11.0.0 were "milestones" and 11.0.0 was the first
stable release. 11.0.0 was released on 2024-10-09, one day after the
final publication of Jakarta EE 11 which includes the relevant
specifications.

How were we able to release one day after the publication of the spec?
It's mostly down the to the fact that the specification process is 100%
public and, as things get closer to the final publication date, fewer
and fewer actual changes are made. The Tomcat team was working on Tomcat
11 during the maturation process of Jakarta EE and kept the milestone
releases up-to-date with the spec so that, once it was finally
published, there was actually no additional work to be done.

The publication of the Jakarta EE Web Profile is not relevant to Tomcat
for a number of reasons. Since Tomcat does not officially implement the
EE Web Profile, we did not need to wait for its publication. We only
care about the following specifications, all of which were finalized
along with the Jakarta EE 11 publication on October 2024:

* Jakarta Servlet
* Jakarta Pages (aka JSP)
* Jakarta Expression Language (aka EL)
* Jakarta WebSocket
* Jakarta Authentication (aka JASPIC)

The EE Web Profile includes these specs which may or may not have been
finalized in October, but definitely became final with the publication
of the EE Spec:

* Jakarta Annotations 3.0
* Jakarta Concurrency 3.1
* Jakarta Contexts and Dependency Injection 4.1
* Jakarta Data 1.0
* Jakarta Debugging Support for Other Languages 2.0
* Jakarta Dependency Injection 2.0
* Jakarta Enterprise Beans 4.0 Lite
* Jakarta Faces 4.1
* Jakarta Interceptors 2.2
* Jakarta JSON Binding 3.0
* Jakarta JSON Processing 2.1
* Jakarta Persistence 3.2
* Jakarta RESTful Web Services 4.0
* Jakarta Security 4.0
* Jakarta Standard Tag Library 3.0
* Jakarta Transactions 2.0
* Jakarta Validation 3.1

Tomcat *can* be used with these Web Profile specifications, but Tomcat
does not provide implementations of any of those -- the application must
bring them along. Or you can use Apache TomEE with is a Tomcat core plus
the appropriate implementations of the 17 additional specifications that
are a part of the EE Web Profile which Tomcat does not provide.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.




-
To unsubscribe, e-mail: