You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2014/04/24 15:16:57 UTC
lean and mean Tomcat 7 configuration
Hi.
Starting from a vanilla current Tomcat 7 download (*), on a Linux server
I have looked at the on-line Configuration documentation of Tomcat 7, but that kind of
information is not really provided there.
We would like to configure this tomcat to be as lean and mean as possible, within the
following parameters :
- it only needs one default "Host"
- we do not use the Manager
- it is running a single webapp, which has only a few servlets and no JSP pages at all.
- the application is never deployed/undeployed "live"; when we make a change, we always
restart Tomcat
- all accesses to Tomcat happen through an Apache httpd front-end on the same host, via
mod_jk and Tomcat's AJP Connector
- there is no authentication done at the Tomcat level; if AAA is done, it is done at the
httpd level and passed on via mod_jk
- there is no need for an Access log (we have one at the Apache httpd front-end level)
- the running webapp does not leak memory, does not start "ThreadLocal"'s (whatever that is)
- we do not need SSL (so do we need APR ? does it bring anything in this case ?)
- the request volume is low, in relation to what I see sometimes being mentioned on this
Users List (say peak may be 10 per second, and it does not happen often)
- we would like only one logfile, for everything which Tomcat itself produces (currently,
it seems to produce half a dozen, most of them empty but nevertheless rotated on a daily base)
- we would like a separate logfile for the one webapp, because it unfortunately produces a
bunch of junk output to sysout and/or syserr, and there is no way to turn that off at the
webapp level, and we do not have the source code of that webapp.
(Basically, I would like to "junk" this output to /dev/null, but how do I do that with the
standard Tomcat JULI logging ?)
So basically, what can we remove from the standard "server.xml" and the standard
"logging.properties", and which may be meaningful to remove ?
I am starting from the premise that whatever ones adds, uses some resources in some way.
But I also do not want to spend hours wringing the last 1 KB out of memory; 1 MB might be
worthwhile though, specially if it is there for each running webapp instance.
For example, in the standard server.xml, there are the following Listeners listed at the
beginning :
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JasperListener" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
Do they use resources ? are they useful/used in the above scenario ? would removing them
create a problem ? would removing them save 1 MB or more (or 1 M CPU cycles per request ) ?
Thanks for any tips.
(*) Ok, that is not really true, it is a Linux Debian packaged Tomcat. But I don't think
that the server.xml and logging.properties are different from the official Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: lean and mean Tomcat 7 configuration
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 4/24/2014 10:52 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 4/24/14, 9:16 AM, André Warnier wrote:
>> Starting from a vanilla current Tomcat 7 download (*), on a Linux
>> server
>>
>> I have looked at the on-line Configuration documentation of Tomcat
>> 7, but that kind of information is not really provided there.
>>
>> We would like to configure this tomcat to be as lean and mean as
>> possible, within the following parameters :
> Strong suggestion: use a separate CATALINA_BASE if you aren't already
> doing so. I'm not sure how complicated this is to do with Debian's
> package-managed version of Tomcat.
>
>> - it only needs one default "Host"
> Default.
>
>> - we do not use the Manager
> Default.
>
>> - it is running a single webapp, which has only a few servlets and
>> no JSP pages at all.
> Easy: dump your WAR in the right place. Remove the ROOT WAR (or
> replace it).
>
>> - the application is never deployed/undeployed "live"; when we make
>> a change, we always restart Tomcat - all accesses to Tomcat happen
>> through an Apache httpd front-end on the same host, via mod_jk and
>> Tomcat's AJP Connector - there is no authentication done at the
>> Tomcat level; if AAA is done, it is done at the httpd level and
>> passed on via mod_jk
> Ok.
>
>> - there is no need for an Access log (we have one at the Apache
>> httpd front-end level)
> The access log is sometimes useful. Disabling it is easy, though.
>
>> - the running webapp does not leak memory, does not start
>> "ThreadLocal"'s (whatever that is) - we do not need SSL (so do we
>> need APR ? does it bring anything in this case ?)
> APR will not really help you. I would recommend using the BIO
> connector since you are using only AJP from httpd. If you need to
> handle many many incoming AJP connections, perhaps the NIO connector
> would be better.
>
>> - the request volume is low, in relation to what I see sometimes
>> being mentioned on this Users List (say peak may be 10 per second,
>> and it does not happen often)
> Ok.
>
>> - we would like only one logfile, for everything which Tomcat
>> itself produces (currently, it seems to produce half a dozen, most
>> of them empty but nevertheless rotated on a daily base)
> The default logging.properties creates lots of log files. Feel free to
> remove/customize it. By not deploying additional applications
> (host-manager, manager, etc.), you may get some log files created but
> never containing any logs. Just remove/comment those from
> logging.properties.
>
>> - we would like a separate logfile for the one webapp, because it
>> unfortunately produces a bunch of junk output to sysout and/or
>> syserr, and there is no way to turn that off at the webapp level,
>> and we do not have the source code of that webapp.
> swallowOutput="true", and configure the logger in logging.properties.
>
>> (Basically, I would like to "junk" this output to /dev/null, but
>> how do I do that with the standard Tomcat JULI logging ?)
> Umm... I'm not sure. Does JULI have a DevNullLogger? I'd have to look.
>
>> So basically, what can we remove from the standard "server.xml" and
>> the standard "logging.properties", and which may be meaningful to
>> remove ?
> I would generally leave server.xml alone. Nothing in there will slow
> you down, etc. If you are passionate about it, remove the AccessLogValve.
>
> logging.properties is another story. I would comment-out anything
> related to the web applications you are /not/ deploying (e.g.
> host-manager, manager, etc.) and add something for your own
> application so the logs so somewhere other than catalina.out (or
> wherever Debian puts it). Then you can figure out whether or not there
> is a /dev/null logger you can use. Perhaps you can use a standard file
> logger and point it at /dev/null. (Why don't you want your logs?)
>
>> I am starting from the premise that whatever ones adds, uses some
>> resources in some way. But I also do not want to spend hours
>> wringing the last 1 KB out of memory; 1 MB might be worthwhile
>> though, specially if it is there for each running webapp instance.
> Most of the stuff in server.xml are lifecycle listeners that do
> something on startup and generally don't do anything after that. The
> memory leak checking stuff only really affects you on shutdown and
> will tell you if you have any problems. Again, if you feel passionate,
> you can pretty much remove them all (except for Jasper, if you use any
> JSPs).
Even if you do use JSP, you may be able to remove the Jasper listener if
you pre-compile the JSPs at build time and only deploy the generated
classes.
-Terence Bandoian
>
>> For example, in the standard server.xml, there are the following
>> Listeners listed at the beginning : <Listener
>> className="org.apache.catalina.core.AprLifecycleListener"
>> SSLEngine="on" />
> Does nothing if APR is not installed. No runtime impact except that
> the AprLifecycleListener class is loaded into memory and there is an
> instance of it laying around.
>
>> <Listener className="org.apache.catalina.core.JasperListener" />
> Enables JSP. Required if you want JSPs. Oddly enough, the reference in
> the config file for /docs/jasper-howto.html does not mention the
> listener at all. :(
>
>> <Listener
>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>> />
> Nice, but not necessary. No runtime impact other than loading a few
> classes at startup that you may not actually need.
>
>> <Listener
>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>> />
> Necessary if you use global resources in server.xml. Do you? No
> runtime impact other than the listener instance in memory.
>
>> <Listener
>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>> />
> Since you aren't doing hot-re-deployments, this one has no runtime
> impact, either.
>
>> Do they use resources ? are they useful/used in the above scenario
>> ? would removing them create a problem ? would removing them save 1
>> MB or more (or 1 M CPU cycles per request ) ?
> You might save a few tens of kilobytes.
>
>> Thanks for any tips.
>>
>> (*) Ok, that is not really true, it is a Linux Debian packaged
>> Tomcat. But I don't think that the server.xml and
>> logging.properties are different from the official Tomcat.
> How do you like the Debian-packaged version?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTWTMxAAoJEBzwKT+lPKRYWuEQAK3UskICfBdYktY8ROhHLeEA
> sUg/VXiC1+pJ6UaMcBNXPrAYtx+y9xmbZNFm8Eko5nZ8cQZarexaLoUOZAzBaSiG
> rig5TaWPsfjJEnvUGjz2vbt5NCBDeTUotydp3PEkRSmfeTlyAlE/bgIALgur/uzK
> FM7S4/iJ5pG+xdo7L4/IfPo9Cw8OgOh0cMYBmnSaiuKnz6UuBf9X1oo/ks9dbKmE
> bVR+nvjEAN75fGnn+1k3PgFdWlJuHeJb3VGrpC/Hsa8j8EOzl/CDrBC42zFNzyd6
> otQiOR4B6JuO8HMbjQqyg71lEkiPpP3s/JDgk+plcS5lF4vR3St2CxSzMLXVfuw7
> bs6FIQFkgcFS1SK0sp/dtXnOJxMfiEEqWIknYLBH59pcaDZDKubsY0uaZ+XedaPv
> ClnFaSjGamC1YL/MYLvJM1dXN3pTrEO731j4VCk75H2bEDsQFRuoMFAh/BZizQDg
> 4UP9q9Kms58Js+TU9hJzG+iK6e7/t18PyDNgPt5MNcQroSHC9M7n8u6V0xpRCgD2
> Fx3e6iD/xDjc+myxnIjmzFq86CrYnLTvlpQN+YG+FbWIeyGYjRg8tImBChp2vpe+
> mEf04l8+Nr5O8IZ3TV/XtjdParwRx4mmPy0UF6xlQSHV10HOxBb5w52kLibwCeIy
> OVfkd/Ye1TyGCQ6Q9hR0
> =ZjS4
> -----END PGP SIGNATURE-----
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: lean and mean Tomcat 7 configuration
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 4/24/14, 9:16 AM, André Warnier wrote:
> Starting from a vanilla current Tomcat 7 download (*), on a Linux
> server
>
> I have looked at the on-line Configuration documentation of Tomcat
> 7, but that kind of information is not really provided there.
>
> We would like to configure this tomcat to be as lean and mean as
> possible, within the following parameters :
Strong suggestion: use a separate CATALINA_BASE if you aren't already
doing so. I'm not sure how complicated this is to do with Debian's
package-managed version of Tomcat.
> - it only needs one default "Host"
Default.
> - we do not use the Manager
Default.
> - it is running a single webapp, which has only a few servlets and
> no JSP pages at all.
Easy: dump your WAR in the right place. Remove the ROOT WAR (or
replace it).
> - the application is never deployed/undeployed "live"; when we make
> a change, we always restart Tomcat - all accesses to Tomcat happen
> through an Apache httpd front-end on the same host, via mod_jk and
> Tomcat's AJP Connector - there is no authentication done at the
> Tomcat level; if AAA is done, it is done at the httpd level and
> passed on via mod_jk
Ok.
> - there is no need for an Access log (we have one at the Apache
> httpd front-end level)
The access log is sometimes useful. Disabling it is easy, though.
> - the running webapp does not leak memory, does not start
> "ThreadLocal"'s (whatever that is) - we do not need SSL (so do we
> need APR ? does it bring anything in this case ?)
APR will not really help you. I would recommend using the BIO
connector since you are using only AJP from httpd. If you need to
handle many many incoming AJP connections, perhaps the NIO connector
would be better.
> - the request volume is low, in relation to what I see sometimes
> being mentioned on this Users List (say peak may be 10 per second,
> and it does not happen often)
Ok.
> - we would like only one logfile, for everything which Tomcat
> itself produces (currently, it seems to produce half a dozen, most
> of them empty but nevertheless rotated on a daily base)
The default logging.properties creates lots of log files. Feel free to
remove/customize it. By not deploying additional applications
(host-manager, manager, etc.), you may get some log files created but
never containing any logs. Just remove/comment those from
logging.properties.
> - we would like a separate logfile for the one webapp, because it
> unfortunately produces a bunch of junk output to sysout and/or
> syserr, and there is no way to turn that off at the webapp level,
> and we do not have the source code of that webapp.
swallowOutput="true", and configure the logger in logging.properties.
> (Basically, I would like to "junk" this output to /dev/null, but
> how do I do that with the standard Tomcat JULI logging ?)
Umm... I'm not sure. Does JULI have a DevNullLogger? I'd have to look.
> So basically, what can we remove from the standard "server.xml" and
> the standard "logging.properties", and which may be meaningful to
> remove ?
I would generally leave server.xml alone. Nothing in there will slow
you down, etc. If you are passionate about it, remove the AccessLogValve.
logging.properties is another story. I would comment-out anything
related to the web applications you are /not/ deploying (e.g.
host-manager, manager, etc.) and add something for your own
application so the logs so somewhere other than catalina.out (or
wherever Debian puts it). Then you can figure out whether or not there
is a /dev/null logger you can use. Perhaps you can use a standard file
logger and point it at /dev/null. (Why don't you want your logs?)
> I am starting from the premise that whatever ones adds, uses some
> resources in some way. But I also do not want to spend hours
> wringing the last 1 KB out of memory; 1 MB might be worthwhile
> though, specially if it is there for each running webapp instance.
Most of the stuff in server.xml are lifecycle listeners that do
something on startup and generally don't do anything after that. The
memory leak checking stuff only really affects you on shutdown and
will tell you if you have any problems. Again, if you feel passionate,
you can pretty much remove them all (except for Jasper, if you use any
JSPs).
> For example, in the standard server.xml, there are the following
> Listeners listed at the beginning : <Listener
> className="org.apache.catalina.core.AprLifecycleListener"
> SSLEngine="on" />
Does nothing if APR is not installed. No runtime impact except that
the AprLifecycleListener class is loaded into memory and there is an
instance of it laying around.
> <Listener className="org.apache.catalina.core.JasperListener" />
Enables JSP. Required if you want JSPs. Oddly enough, the reference in
the config file for /docs/jasper-howto.html does not mention the
listener at all. :(
> <Listener
> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
> />
Nice, but not necessary. No runtime impact other than loading a few
classes at startup that you may not actually need.
> <Listener
> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
> />
Necessary if you use global resources in server.xml. Do you? No
runtime impact other than the listener instance in memory.
> <Listener
> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
> />
Since you aren't doing hot-re-deployments, this one has no runtime
impact, either.
> Do they use resources ? are they useful/used in the above scenario
> ? would removing them create a problem ? would removing them save 1
> MB or more (or 1 M CPU cycles per request ) ?
You might save a few tens of kilobytes.
> Thanks for any tips.
>
> (*) Ok, that is not really true, it is a Linux Debian packaged
> Tomcat. But I don't think that the server.xml and
> logging.properties are different from the official Tomcat.
How do you like the Debian-packaged version?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTWTMxAAoJEBzwKT+lPKRYWuEQAK3UskICfBdYktY8ROhHLeEA
sUg/VXiC1+pJ6UaMcBNXPrAYtx+y9xmbZNFm8Eko5nZ8cQZarexaLoUOZAzBaSiG
rig5TaWPsfjJEnvUGjz2vbt5NCBDeTUotydp3PEkRSmfeTlyAlE/bgIALgur/uzK
FM7S4/iJ5pG+xdo7L4/IfPo9Cw8OgOh0cMYBmnSaiuKnz6UuBf9X1oo/ks9dbKmE
bVR+nvjEAN75fGnn+1k3PgFdWlJuHeJb3VGrpC/Hsa8j8EOzl/CDrBC42zFNzyd6
otQiOR4B6JuO8HMbjQqyg71lEkiPpP3s/JDgk+plcS5lF4vR3St2CxSzMLXVfuw7
bs6FIQFkgcFS1SK0sp/dtXnOJxMfiEEqWIknYLBH59pcaDZDKubsY0uaZ+XedaPv
ClnFaSjGamC1YL/MYLvJM1dXN3pTrEO731j4VCk75H2bEDsQFRuoMFAh/BZizQDg
4UP9q9Kms58Js+TU9hJzG+iK6e7/t18PyDNgPt5MNcQroSHC9M7n8u6V0xpRCgD2
Fx3e6iD/xDjc+myxnIjmzFq86CrYnLTvlpQN+YG+FbWIeyGYjRg8tImBChp2vpe+
mEf04l8+Nr5O8IZ3TV/XtjdParwRx4mmPy0UF6xlQSHV10HOxBb5w52kLibwCeIy
OVfkd/Ye1TyGCQ6Q9hR0
=ZjS4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: lean and mean Tomcat 7 configuration
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-04-24 17:16 GMT+04:00 André Warnier <aw...@ice-sa.com>:
> Hi.
>
> Starting from a vanilla current Tomcat 7 download (*), on a Linux server
>
> (Chris already answered most of questions...)
>
> - we would like only one logfile, for everything which Tomcat itself
> produces (currently, it seems to produce half a dozen, most of them empty
> but nevertheless rotated on a daily base)
> - we would like a separate logfile for the one webapp, because it
> unfortunately produces a bunch of junk output to sysout and/or syserr, and
> there is no way to turn that off at the webapp level, and we do not have the
> source code of that webapp.
> (Basically, I would like to "junk" this output to /dev/null, but how do I do
> that with the standard Tomcat JULI logging ?)
Does that app write to stderr/stdout without using any logging library?
If so, then you can configure <Context> to catch those writes and
redirect them to logging system.
The context will use ServletContext.log(..) for those messages.
Then you can configure "level" for that log category so that the
messages are not logged anywhere.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org