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

#!/bin/bash
# -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’`
OUTFILE=”tomcat-stats-${TODAY}.csv”
#
#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
fi
# # 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
   do
      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>”
                ;;
            *) ;;
      esac
    done < /tmp/tomcat-status
# # Now is the time to write the data to the csv-file
  echo “${TIME},${JVM_VALUE}${HTTP_MAX_THREADS}${HTTP_BSY_THREADS}
  ${MODJK_MAX_THREADS}${MODJK_BSY_THREADS}${SESSION_CNT}” >>$OUTFILE
exit

*) 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.