You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2011/06/20 21:12:04 UTC
Slower start with Tomcat 7.0.14 and higher
Start up takes around 20 seconds longer with Tomcat 7.0.14 and 7.0.16
than it did with 7.0.12.
This appears to be due to time spent scanning jars for annotations,
etc. We have a number of /very /large jar files in both the base
classloader for Tomcat (which we're embedding) and in our web apps.
This raises 2 questions:
1. Was jar scanning not working for such uses cases in 7.0.12, e.g.
was the scanning incomplete?
2. Did something change to make the performance of the scanning
perform much worse in 7.0.14 /and /7.0.16 than in 7.0.12?
* The release notes suggest that 7.0.14 had an issue and that
it was resolved in 7.0.16, but we're seeing both 7.0.14 and
7.0.16 being approximately equally slow to start up.
Clearly the answer to both questions could be "yes". If only #2 is a
"yes", then I'd really like to get this resolved and get back to the
previous performance. If, however, #1 explains much of the degradation,
then I'll need to look into excluding jars from scanning, etc.
--
Jess Holle
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/20/2011 2:41 PM, Jess Holle wrote:
> On 6/20/2011 2:16 PM, Mark Thomas wrote:
>> It should have improved for the majority of use cases in 7.0.14 but at
>> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
>> 7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
>> to the pre 7.0.14 performance levels.
> We're embedding Tomcat in a larger server process and the base
> classloader includes a lot more than CATALINA_BASE/lib. Some of these
> jars are huge -- and the intent (and effect) is that these are shared
> by any/all web app instances.
>
> My initial guess is that the 7.0.16 fix may have overlooked this
> possibility and be special-cased for jars in CATALINA_BASE/lib vs.
> applying to any jar coming from the base classloader and a file: (vs.
> HTTP or JNDI) URL.
>> It looks like there may still be an issue. Profiling data on where the
>> time is being spent would be useful.
> I should be able to drum up such a profile here in a bit...
There's a lot more data in the profile than I really want to post/share,
but with heavy/frequent (20ms) VisualVM sampling profiler overhead, I
see that ~31 seconds are spent on ContextConfig.webConfig() -- mostly in
ContextConfig.processAnnotations(), etc. I also see ~8 seconds spent on
TldConfig.execute(). The numbers are clearly inflated from the original
metrics due to the crude sampling approach, but the overhead is clearly
in these areas.
--
Jess Holle
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/22/2011 12:44 PM, Caldarale, Charles R wrote:
> I think it can happen, without detection, if you have the same class directly visible to multiple classloaders - which I recall that you do (but perhaps I misunderstood this statement: "the base classloader includes a lot more than CATALINA_BASE/lib. Some of these jars are huge -- and the intent (and effect) is that these are shared by
> any/all web app instances.").
>
> So before pursuing this any further, is the same class visible to more than one classloader in your environment? If not, then there should be no problem, regardless of internal classloader logic.
Overall I'm pretty confident that things are okay here -- especially as
we've been using and testing this configuration for quite some time now.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Slower start with Tomcat 7.0.14 and higher
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jess Holle [mailto:jessh@ptc.com]
> Subject: Re: Slower start with Tomcat 7.0.14 and higher
> Since delegation is downwards
Only for the webapp classloader.
> the only issue that should possibly occur is if a class gets
> loaded in the parent classloader that then needs a class in
> the child (e.g. web app) classloader. That will fail, of
> course, but that's ok as this should never occur.
I think it can happen, without detection, if you have the same class directly visible to multiple classloaders - which I recall that you do (but perhaps I misunderstood this statement: "the base classloader includes a lot more than CATALINA_BASE/lib. Some of these jars are huge -- and the intent (and effect) is that these are shared by
any/all web app instances.").
So before pursuing this any further, is the same class visible to more than one classloader in your environment? If not, then there should be no problem, regardless of internal classloader logic.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
Since delegation is downwards the only issue that should possibly occur
is if a class gets loaded in the parent classloader that then needs a
class in the child (e.g. web app) classloader. That will fail, of
course, but that's ok as this should never occur.
On 6/22/2011 12:27 PM, Caldarale, Charles R wrote:
>> From: Jess Holle [mailto:jessh@ptc.com]
>> Subject: Re: Slower start with Tomcat 7.0.14 and higher
>> Well the classloaders are clearly hierarchical, so only one Class
>> instance is loaded. The fact that both ClassLoaders can see the jar
>> does not result in 2 Class objects
> I think we need some experimentation (or browsing through some really ugly C++ code in the JVM) to verify the above. I have a vague memory of the class dependency resolution being routed through the classloader of the class with the dependency, not the thread's current classloader, thus avoiding downward pointer issues. However, since I've been looking at JVM code since 1.2 days, I can't be sure that's the way it works today without doing some more homework.
>
> If dependency resolution does work the way I remember, then it would be possible for the same .class file to be processed by different classloaders in your environment.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Slower start with Tomcat 7.0.14 and higher
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jess Holle [mailto:jessh@ptc.com]
> Subject: Re: Slower start with Tomcat 7.0.14 and higher
> Well the classloaders are clearly hierarchical, so only one Class
> instance is loaded. The fact that both ClassLoaders can see the jar
> does not result in 2 Class objects
I think we need some experimentation (or browsing through some really ugly C++ code in the JVM) to verify the above. I have a vague memory of the class dependency resolution being routed through the classloader of the class with the dependency, not the thread's current classloader, thus avoiding downward pointer issues. However, since I've been looking at JVM code since 1.2 days, I can't be sure that's the way it works today without doing some more homework.
If dependency resolution does work the way I remember, then it would be possible for the same .class file to be processed by different classloaders in your environment.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Rainer Jung <ra...@kippdata.de>.
On 22.06.2011 19:20, Jess Holle wrote:
> On 6/22/2011 10:16 AM, Jess Holle wrote:
> The only issue I found at this level is that both
> tomcat-juli-adapters.jar and tomcat-juli-adapters.jar are scanned. I'd
> think that all the Tomcat "extras" jars should be in Tomcat's
> out-of-the-box list of jars to be ignored -- unless they actually
> shouldn't be ignored, of course. That's a rather minor issue, though --
> and presumably accounts for very, very little of the startup time.
By coincidence I added them in 3 days ago (r1137541 and r1137754) :)
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/22/2011 10:16 AM, Jess Holle wrote:
> On 6/22/2011 9:08 AM, Mark Thomas wrote:
>>> Another issue is that WEB-INF/lib is visible to the parent classloader
>>> embedding Tomcat and to Tomcat as part of the web application and thus
>>> I'm probably getting double scanning -- though really Tomcat should be
>>> avoiding this by detecting that the same jar file is involved in both
>>> cases. The reasons for the duplication in this classpath are long and
>>> historic. Overall I'd rather not try to unwind this now. I'd
>>> hope/assume that an annotation on a class, e.g. a filter annotation,
>>> would only result in one filter instance irrespective of how many times
>>> that class is visible to the classloader(s) in question.
>> That sounds like it might cause trouble. Classes are identified by the
>> combination of name and class loader so the same class loaded in two
>> different class loaders is treated as a different class. If both the web
>> application class loader and its parent class loader can see WEB-INF/lib
>> I can image all sorts of things may go wrong.
> Well the classloaders are clearly hierarchical, so only one Class
> instance is loaded. The fact that both ClassLoaders can see the jar
> does not result in 2 Class objects -- nor should it result in an
> annotation being applied multiple times. The jars are in fact exactly
> the same here -- as one of the web app's WEB-INF/lib directories is
> visible to the parent classloader. It may be possible to move the
> jars somewhere else so that they're only part of the parent
> classloader, but that will require more reshuffling of the
> longstanding configuration.
I increased the verbosity for the StandardJarScanner logger. Based on
that output everything appears ok for our use case. The only duplicated
jars we have are in WEB-INF/lib which is already automatically ignored
when scanning the classpath.
The only issue I found at this level is that both
tomcat-juli-adapters.jar and tomcat-juli-adapters.jar are scanned. I'd
think that all the Tomcat "extras" jars should be in Tomcat's
out-of-the-box list of jars to be ignored -- unless they actually
shouldn't be ignored, of course. That's a rather minor issue, though --
and presumably accounts for very, very little of the startup time.
--
Jess Holle
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/22/2011 9:08 AM, Mark Thomas wrote:
>> Another issue is that WEB-INF/lib is visible to the parent classloader
>> embedding Tomcat and to Tomcat as part of the web application and thus
>> I'm probably getting double scanning -- though really Tomcat should be
>> avoiding this by detecting that the same jar file is involved in both
>> cases. The reasons for the duplication in this classpath are long and
>> historic. Overall I'd rather not try to unwind this now. I'd
>> hope/assume that an annotation on a class, e.g. a filter annotation,
>> would only result in one filter instance irrespective of how many times
>> that class is visible to the classloader(s) in question.
> That sounds like it might cause trouble. Classes are identified by the
> combination of name and class loader so the same class loaded in two
> different class loaders is treated as a different class. If both the web
> application class loader and its parent class loader can see WEB-INF/lib
> I can image all sorts of things may go wrong.
Well the classloaders are clearly hierarchical, so only one Class
instance is loaded. The fact that both ClassLoaders can see the jar
does not result in 2 Class objects -- nor should it result in an
annotation being applied multiple times. The jars are in fact exactly
the same here -- as one of the web app's WEB-INF/lib directories is
visible to the parent classloader. It may be possible to move the jars
somewhere else so that they're only part of the parent classloader, but
that will require more reshuffling of the longstanding configuration.
>> Given that the JNDI node maps to a file if the web app is expanded -- as
>> mine always is (being deployed originally as an expanded directory in
>> .war layout not as a .ware archive), it seems there should be a "back
>> door" for Tomcat to notice this and simply use the file location to
>> begin with rather than doing any extra temporary file shenanigans in any
>> case. The JNDI wrapping is nice and all, but shouldn't cause a
>> substantially sub-optimal performance approach when it is clear enough
>> how to attain the appropriate File object.
> It should be doing that already. I'll double check
>> Is there any danger -- other than worse performance in use cases I don't
>> have -- in me patching my own Tomcat to always use FileUrlJar? Should
>> this perhaps be a config option? Or possibly a config option based on
>> file size? [FileUrlJar may only be faster for larger jars from what
>> little I know...]
> That local patch should be safe. In terms of config, I'd like to keep
> this as automated as possible. More research required.
>
> For reference, how big are the JAR files we are talking about here?
They range in size from 48K to 46MB. Only 3 jars are over 25MB in size.
--
Jess Holle
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Mark Thomas <ma...@apache.org>.
On 22/06/2011 15:08, Mark Thomas wrote:
> On 21/06/2011 22:58, Jess Holle wrote:
>> If I alter JarFactory to always use FileUrlJar, then my startup is
>> around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12.
>>
>> It turns out the issue is the large jars I have in my WEB-INF/lib
>> directory -- and FileUrlJar is still much faster in this case than using
>> UrlJar even with a JNDI URL.
>
> Interesting. I'll dig into this some more.
OK. I have a patch that I think should fix this generally. It works well
for me locally but it would be good to get some real-life data. Are you
willing to test it?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Mark Thomas <ma...@apache.org>.
On 21/06/2011 22:58, Jess Holle wrote:
> If I alter JarFactory to always use FileUrlJar, then my startup is
> around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12.
>
> It turns out the issue is the large jars I have in my WEB-INF/lib
> directory -- and FileUrlJar is still much faster in this case than using
> UrlJar even with a JNDI URL.
Interesting. I'll dig into this some more.
> Another issue is that WEB-INF/lib is visible to the parent classloader
> embedding Tomcat and to Tomcat as part of the web application and thus
> I'm probably getting double scanning -- though really Tomcat should be
> avoiding this by detecting that the same jar file is involved in both
> cases. The reasons for the duplication in this classpath are long and
> historic. Overall I'd rather not try to unwind this now. I'd
> hope/assume that an annotation on a class, e.g. a filter annotation,
> would only result in one filter instance irrespective of how many times
> that class is visible to the classloader(s) in question.
That sounds like it might cause trouble. Classes are identified by the
combination of name and class loader so the same class loaded in two
different class loaders is treated as a different class. If both the web
application class loader and its parent class loader can see WEB-INF/lib
I can image all sorts of things may go wrong.
> Given that the JNDI node maps to a file if the web app is expanded -- as
> mine always is (being deployed originally as an expanded directory in
> .war layout not as a .ware archive), it seems there should be a "back
> door" for Tomcat to notice this and simply use the file location to
> begin with rather than doing any extra temporary file shenanigans in any
> case. The JNDI wrapping is nice and all, but shouldn't cause a
> substantially sub-optimal performance approach when it is clear enough
> how to attain the appropriate File object.
It should be doing that already. I'll double check.
> Is there any danger -- other than worse performance in use cases I don't
> have -- in me patching my own Tomcat to always use FileUrlJar? Should
> this perhaps be a config option? Or possibly a config option based on
> file size? [FileUrlJar may only be faster for larger jars from what
> little I know...]
That local patch should be safe. In terms of config, I'd like to keep
this as automated as possible. More research required.
For reference, how big are the JAR files we are talking about here?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
If I alter JarFactory to always use FileUrlJar, then my startup is
around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12.
It turns out the issue is the large jars I have in my WEB-INF/lib
directory -- and FileUrlJar is still much faster in this case than using
UrlJar even with a JNDI URL.
Another issue is that WEB-INF/lib is visible to the parent classloader
embedding Tomcat and to Tomcat as part of the web application and thus
I'm probably getting double scanning -- though really Tomcat should be
avoiding this by detecting that the same jar file is involved in both
cases. The reasons for the duplication in this classpath are long and
historic. Overall I'd rather not try to unwind this now. I'd
hope/assume that an annotation on a class, e.g. a filter annotation,
would only result in one filter instance irrespective of how many times
that class is visible to the classloader(s) in question.
Given that the JNDI node maps to a file if the web app is expanded -- as
mine always is (being deployed originally as an expanded directory in
.war layout not as a .ware archive), it seems there should be a "back
door" for Tomcat to notice this and simply use the file location to
begin with rather than doing any extra temporary file shenanigans in any
case. The JNDI wrapping is nice and all, but shouldn't cause a
substantially sub-optimal performance approach when it is clear enough
how to attain the appropriate File object.
Is there any danger -- other than worse performance in use cases I don't
have -- in me patching my own Tomcat to always use FileUrlJar? Should
this perhaps be a config option? Or possibly a config option based on
file size? [FileUrlJar may only be faster for larger jars from what
little I know...]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/20/2011 5:05 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jess,
>
> On 6/20/2011 5:47 PM, Jess Holle wrote:
>> On 6/20/2011 4:35 PM, Christopher Schultz wrote:
>>> Maybe you could move /some/ of them?
>> The libraries in question are actually loaded by the application
>> classloader -- as is Tomcat's Bootstrap class.
> Application being that which embeds Tomcat, or the webapp(s) eventually
> deployed by Tomcat? ;)
The embedding application, i.e. the system classloader.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jess,
On 6/20/2011 5:47 PM, Jess Holle wrote:
> On 6/20/2011 4:35 PM, Christopher Schultz wrote:
>>
>> Maybe you could move /some/ of them?
>
> The libraries in question are actually loaded by the application
> classloader -- as is Tomcat's Bootstrap class.
Application being that which embeds Tomcat, or the webapp(s) eventually
deployed by Tomcat? ;)
> And, yes, eventually I'll want to scan some of these jars for
> annotations -- but not all unless this is really fast/cheap.
Understood.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3/xD4ACgkQ9CaO5/Lv0PBtRgCeKEYB7FTVUwmYdLAB/vdmx4zk
JpQAn3PeX7nefRt6jMxjZrke5BdoFskW
=NpC7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jess,
>
> On 6/20/2011 3:41 PM, Jess Holle wrote:
>> On 6/20/2011 2:16 PM, Mark Thomas wrote:
>>> It should have improved for the majority of use cases in 7.0.14 but at
>>> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
>>> 7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
>>> to the pre 7.0.14 performance levels.
>> We're embedding Tomcat in a larger server process and the base
>> classloader includes a lot more than CATALINA_BASE/lib. Some of these
>> jars are huge -- and the intent (and effect) is that these are shared by
>> any/all web app instances.
> Couldn't you place the libraries in question at a level /higher/ than
> Tomcat's base ClassLoader? Or, do you need some of those libraries to be
> scanned for annotations but not all.
>
> Maybe you could move /some/ of them?
The libraries in question are actually loaded by the application
classloader -- as is Tomcat's Bootstrap class.
And, yes, eventually I'll want to scan some of these jars for
annotations -- but not all unless this is really fast/cheap.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jess,
On 6/20/2011 3:41 PM, Jess Holle wrote:
> On 6/20/2011 2:16 PM, Mark Thomas wrote:
>> It should have improved for the majority of use cases in 7.0.14 but at
>> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
>> 7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
>> to the pre 7.0.14 performance levels.
>
> We're embedding Tomcat in a larger server process and the base
> classloader includes a lot more than CATALINA_BASE/lib. Some of these
> jars are huge -- and the intent (and effect) is that these are shared by
> any/all web app instances.
Couldn't you place the libraries in question at a level /higher/ than
Tomcat's base ClassLoader? Or, do you need some of those libraries to be
scanned for annotations but not all.
Maybe you could move /some/ of them?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3/vR8ACgkQ9CaO5/Lv0PCeKgCfbB795HYTMgkBneId0vXMt0cx
ohMAoLU9qbtny5RUTbejsX5LcO2ddnm2
=y23R
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/20/2011 3:16 PM, Rainer Jung wrote:
> Sure we want to make scaning as fast as possible. But did you realize,
> that you can exclude Jars from being scanned? There's a list f
> exclusions defined in catalina.properties.
Yes -- and I'll go there is the speed from 7.0.12 (which was quite
reasonable despite scanning all our jars) cannot be re-attained.
I might go there anyway for *some* of our jars, but I will likely want
to start doing more via annotations and less via web.xml as well -- and
would like to minimize the startup performance penalty entailed in doing so.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Rainer Jung <ra...@kippdata.de>.
On 20.06.2011 21:41, Jess Holle wrote:
> On 6/20/2011 2:16 PM, Mark Thomas wrote:
>> It should have improved for the majority of use cases in 7.0.14 but at
>> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
>> 7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
>> to the pre 7.0.14 performance levels.
> We're embedding Tomcat in a larger server process and the base
> classloader includes a lot more than CATALINA_BASE/lib. Some of these
> jars are huge -- and the intent (and effect) is that these are shared by
> any/all web app instances.
>
> My initial guess is that the 7.0.16 fix may have overlooked this
> possibility and be special-cased for jars in CATALINA_BASE/lib vs.
> applying to any jar coming from the base classloader and a file: (vs.
> HTTP or JNDI) URL.
>> It looks like there may still be an issue. Profiling data on where the
>> time is being spent would be useful.
> I should be able to drum up such a profile here in a bit...
Sure we want to make scaning as fast as possible. But did you realize,
that you can exclude Jars from being scanned? There's a list f
exclusions defined in catalina.properties.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Jess Holle <je...@ptc.com>.
On 6/20/2011 2:16 PM, Mark Thomas wrote:
> It should have improved for the majority of use cases in 7.0.14 but at
> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
> 7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
> to the pre 7.0.14 performance levels.
We're embedding Tomcat in a larger server process and the base
classloader includes a lot more than CATALINA_BASE/lib. Some of these
jars are huge -- and the intent (and effect) is that these are shared by
any/all web app instances.
My initial guess is that the 7.0.16 fix may have overlooked this
possibility and be special-cased for jars in CATALINA_BASE/lib vs.
applying to any jar coming from the base classloader and a file: (vs.
HTTP or JNDI) URL.
> It looks like there may still be an issue. Profiling data on where the
> time is being spent would be useful.
I should be able to drum up such a profile here in a bit...
--
Jess Holle
Re: Slower start with Tomcat 7.0.14 and higher
Posted by Mark Thomas <ma...@apache.org>.
On 20/06/2011 20:12, Jess Holle wrote:
> Start up takes around 20 seconds longer with Tomcat 7.0.14 and 7.0.16
> than it did with 7.0.12.
>
> This appears to be due to time spent scanning jars for annotations,
> etc. We have a number of /very /large jar files in both the base
> classloader for Tomcat (which we're embedding) and in our web apps.
>
> This raises 2 questions:
>
> 1. Was jar scanning not working for such uses cases in 7.0.12, e.g.
> was the scanning incomplete?
Not that I am aware of.
> 2. Did something change to make the performance of the scanning
> perform much worse in 7.0.14 /and /7.0.16 than in 7.0.12?
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to the pre 7.0.14 performance levels.
> * The release notes suggest that 7.0.14 had an issue and that
> it was resolved in 7.0.16, but we're seeing both 7.0.14 and
> 7.0.16 being approximately equally slow to start up.
>
> Clearly the answer to both questions could be "yes". If only #2 is a
> "yes", then I'd really like to get this resolved and get back to the
> previous performance. If, however, #1 explains much of the degradation,
> then I'll need to look into excluding jars from scanning, etc.
It looks like there may still be an issue. Profiling data on where the
time is being spent would be useful.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org