30. Apr. 2009

Lets assume you have enabled the monitoring capabilities of your tomcat.
If you do not know how to achieve this see my earlier posting here about.

Now it is cool to monitor your application on a regular basis.
Because I’m used to shell scripting in LINUX I present you here a scripting solution within a bash shell. But I’m sure you can do the same in Windows.
The idea is to set up a cron job ( for windows use the scheduler) and get the statuspage from your tomcat every – lets say – five minutes.
Get some of the interesting values out of this page and save them in a csv – File.
Create a new file every day. Perhaps you want to use this files as input for a spreadsheet program to create some nice charts.

But to be honest – this is a very special script – you have to adopt it to your needs.
This are the basic prerequisites:

  • you need linux to run it (this script is developed on a SUSE – Distribution)
  • eventually you need to install some tools (I think the w3m tool is not bundled with every linux distribution)
  • this script only! works correct with a tomcat 6.0 version

# -configure below-

HTTPPORT="8080"    # The http Port of your tomcat
JKPORT="8709"      # The Modjk Port of your tomcat (if your tomcat should be reachable from a apache webserver)
SERVER="localhost:$HTTPPORT" # you can even monitor a tomcat on another server!
USER="tomcat-oper" # the account and
PW="IwantItAll"    # password you have defined in tomcat-users.xml
APPL="CoolAppl"    # The name of your application
# -configure above-
TODAY=`date ‘+%m-%d-%y’`
TIME=`date ‘+%H:%M:%S’`
#set -x   # uncomment if you want to improve the script or if you are searching for a bug
# # If there is no csv-file create one and put a headerline in
if !(test -e $OUTFILE) then
  echo "Time,FreeMemory,UsedMemory,MaxMemory,HttpThreadsMax,
  HttpThreadsBusy,ModJKThreads,ModJKThreadsBusy,Sessions" > $OUTFILE
# # get the statuspage from tomcat – filter it for the wanted informations – and create a temporary file
  w3m -dump http://${USER}:${PW}@${SERVER}/manager/status/all| \
  egrep "(memory|thread|Active sessions|
  ^JVM|$HTTPPORT|$JKPORT|${APPL})" >/tmp/tomcat-status
# put the values in variables / uncomment to get a better understanding of the process
while read line
      case $line in
           JVM) read line
                JVM_VALUE=`echo $line | awk ‘{print($3 "," $7 "," $11)}’`
#               uncomment below if you want to debug
#               echo "JVM_VALUE: <$JVM_VALUE>"

            *${HTTPPORT}) read line
                HTTP_MAX_THREADS=`echo $line |awk ‘{print("," $3)}’`
#               uncomment if you want to debug
#               echo "HTTP_MAX_THREADS: <$HTTP_MAX_THREADS>"
                HTTP_BSY_THREADS=`echo $line |awk ‘{print("," $11)}’`
#               uncomment
below if you want to debug
#               echo "HTTP_BSY_THREADS: <$HTTP_BSY_THREADS>"
            *${JKPORT}) read line
                MODJK_MAX_THREADS=`echo $line |awk ‘{print("," $3)}’`
#               uncomment below if you want to debug
#               echo "MODJK_MAX_THREADS: <$MODJK_MAX_THREADS>"
                MODJK_BSY_THREADS=`echo $line |awk ‘{print("," $11)}’`
#               uncomment below if you want to debug
#               echo "MODJK_BSY_THREADS: <$MODJK_BSY_THREADS>"
            *${APPL}) read line
                SESSION_CNT=`echo $line |awk ‘{print("," $3)}’`
#               uncomment below if you want to debug
#               echo "SESSION_CNT: <$SESSION_CNT>"
            *) ;;
    done < /tmp/tomcat-status
# # Now is the time to write the data to the csv-file

*) be aware that based on word wrapping this script might not work instantly

Create a scriptfile (e.g. tomcat-check.sh) and apply the script to your tomcat. Then edit your crontab.

There should be a line like:
"*/5 * * * * cd ~/statistics; ./tomcat-check.sh 1>tomcat-check.log 2>&1"

And then the script should create the csv-files. I’m not used to excel – but even I managed to create a more or less interesting diagram from this data. Note how regular the memory behaves while there is no user session.

Tomcat Monitoring Graphic 

7. Apr. 2009

The Time to live (TTL)s occuring  in the Domain Name System (DNS), where they are set by an authoritative nameserver for a particular resource record can help us speeding up domain transfers rfom one server to another.

When a caching (recursive) nameserver queries the authoritative nameserver for a resource record, it will cache that record for the time (in seconds) specified by the TTL. If a stub resolver queries the caching nameserver for the same record before the TTL has expired, the caching server will simply reply with the already cached resource record rather than retrieve it from the authoritative nameserver again.

This is a service intended to speed up DNS queries and to prevent load issues on authoritative nameservers. Therefore shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimize disruptions.

And this is exactly what we can use to speed up the transfer time of our domain to move. At least a day before the big bang to happens we enter our Hosting Panel trilling down to the DNS section within and lower the TTL for each relevant definition within the definitions of the domain in question.

The units used are seconds. A common TTL value for DNS is 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that if a DNS record was changed, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Lowering it should be done with some respect about the idea behind and therefore the new value does not really should be close to 1 or so, but going with 600 for a day will for sure not harm.

When we now change the nameserver entry within our Registrar’s Service, all old values will get invalidated within 10 minutes and the new authoritative nameserver will get asked instead.

So all the traffic should then get routed over to the new server in a blink and the higher value there for the TTL will propagate again through the World Wide Web.

2. Feb. 2009

So you have a wonderful java-servlet and you have a stable and reasonable fast application server like tomcat? But sometimes you have performance breakdowns.

  • Sometimes the application seems to be frozen.
  • Sometimes you just want to know what the hell
    is going on with your application.

So the best way is to say:
ÑPlease my little tomcat, tell me ñ how do you feel right now?ì

And if you choose the right method you will get some answers.
The good news ahead ñ it isn’t very difficult to get the information.

You just have to enable the tomcat console. And furthermore you should enable the printout of the garbage collects.
(type "java -X" to get the right gc options for your java-version – normally something like verbose:gc. I will show you in detail in another article)

Just edit the tomcat-users.xml File.

You have to add the roles: manager and admin and add a user and a password that meets your needs. Invent your own username and password and keep it secret. Because userid and password are not encrypted (if you do not explicitly configure https as protocol) you should keep in mind that this is no high sophisticated security.

Tomcat Monitoring

Nevertheless – save your tomcat-users.xml file and restart tomcat. If your tomcat listens on the standard port (8080) give the manager console a try:


You will be prompted for a username and password – if you can remember the values you had put in the tomcat-user.xml file – go on and put them in. So you can see the console – not very exciting – thats true. Here you can just see how many sessions are currently active in an application . And if you want to have fun and you are !not the responsible person for this service you can easily stop an application within the tomcat.

But to be more serious ñ now choose the link in the upper right corner (Server Status) and again the link in the upper right corner (Complete Server Status).
Or just enter:


Take some time to explore the page. Reload the page several times ñ look at how the connections fall and rise. Don’t forget to check the Memory ñ is enough free memory left ? What is the state of the connections ñ are there any connections left. How many threads are busy? How many spare threads do you have? Perhaps you have to adjust the values in the server.conf file.

Can you imagine that it is very easy to get this values extracted and in a "cvs"-file on a regular basis ? So you can get historical values – But that is subject for an own article.

next »