tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tomcat: one user per application
Date Mon, 10 Jun 2013 16:44:49 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 6/10/13 11:56 AM, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> Mihamina,
>> 
>> On 6/10/13 7:12 AM, Mihamina Rakotomandimby wrote:
>>> I have one Tomcat instance, which has several applications 
>>> (containers)
>> 
>> Note: these are not "containers" (at least not in any
>> spec-recognized way). Tomcat is the container, the webapps are
>> called "contexts" -- or just webapps usually.
>> 
>>> On my installation, when Tomcat is running, only "java"
>>> process owned by "tomcat" is listed.
>>> 
>>> When the "java" process gets 100% CPU, I would like to be able
>>> to differentiate which application is it about.
>> 
>> You can only do this by taking a series of thread-dumps (maybe 1
>> every 5 seconds for 15 or 20 seconds) and comparing them to each
>> other. You can probably find out which threads are doing a lot of
>> work (because they are running a lot of code over the time
>> period) and which applications are being used (because of the
>> content of the stack traces).
>> 
>> Of course, you have to have a way to detect "high" CPU usage
>> (100% probably isn't good enough) and then trigger these thread
>> dumps, etc.
>> 
>>> One solution, for me, is to be able to run one java process
>>> per war under a (pre-created) system user. I would like to keep
>>> only one Tomcat instance.
>> 
>> You can have one of these, but not both. You *can* have a single 
>> Tomcat /installation/ and multiple instances, of course (read
>> the RUNNING.txt file that comes with the Tomcat bundle under the 
>> "Advanced" section).
>> 
>> Remember: memory is cheap. It's not that costly to run multiple
>> Tomcat instances. Tomcat requires roughly 12MiB on my system
>> (64-bit with compressed OOPs) with no web applications deployed
>> into it.
>> 
> 
> Alternatively, a "cheap" way of getting at least an idea of what 
> application is using a lot of time :
> 
> In a first approximation, I would tend to believe that an
> application which uses a lot of CPU time, is also probably slow to
> respond (to the user). You could enable the Tomcat Access Log, and
> provide a format which prints to the log, the time needed to
> process each request. Then by examining the log, it should give you
> at least some idea of which application is taking such resources. 
> It is a very rough, and may give you false results. But it is also 
> easier and quicker than any other method which I can think of.

+1

We have such "timing logs" enabled in production for all of our
applications. Periodically running them through a Perl script to run
statistical measurements on them and then graphing them allows us to
focus our optimization efforts where they are actually needed.

For example, one report takes each request (categorized by URI) and
plots a point where the range is the popularity of the request (like,
it represents 100,000 requests) and the value is the average response
time in ms. We have a 3rd axis (displayed as a circle surrounding the
aforementioned point: it's a "bubble chart") whose radius is
proportional to the standard deviation of all of the request times.

This simple graph easily enables us to look at popular, slow requests
and focus our attention there. We can also see which requests have
wildly-varying response times just by looking for "big dots".

We find this immensely useful even when we aren't looking for any
specific problem.

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRtgKBAAoJEBzwKT+lPKRY8V4P/ApwNvLW7AQSdg2a+aFJ/18Y
bU6JUo/NKrw9FWr9+Rd6msL60bEgS5mm3i0i33lx3aZHf8YB+qrd6pA/nZGFUK6t
+XEbM2mk1TTX3gQsE0o2RFungTuFe2yIf5/mdyU3fe4OntEFpPl3cPCQufQ80R13
oyaesMFHSfkBSOsinkgHW+PB4E4rZNfAGcamBIY0+ICNcMmFIF3p57/6v7vm8UXh
hukNAMzAk7waMiK73vvJlbo/GONC7yehaNcCG1hrG9vjUd4H2AcO+3XWNOu+AB7C
1sBq2B7iGasiU5purIcw8raEzH4CGKFsX5azBUCTs69ajULeThWOKHcjQRMQivMW
+N4jw80VYjHIaxDImPxMKCu6uXsQeXHcOqDbPTzvjEl9uOOVa49cR02okQLw9Rbx
/Xj4/bbm2ZcEjrwD6YvOfmvjaLZZaIv0E85w2C567VpzLbYiDC2LKOij2xlDxx6G
BfzMMOxGxkixXTijj3rdmds5k88yBznlUSQ36u+6INuW1Zp/UOquzDHFWGzcNovA
vQ3VE6SsBHqxrchUWnxns9YU41KbDHQx0x0BGsDMUZ5z4DSova3Aiu6g8WfBTAi9
+d+RYzJiJAhSk7C7267ocuz2xtGi3FFpta7H9juEWFKGvBklXf//SCT9PLIr1WQn
70N7B2ropM57pPRcTVnI
=uck1
-----END PGP SIGNATURE-----

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


Mime
View raw message