-----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-----
