Improve Apache Tomcat logging performance

Logging is often an overlooked performance drain on systems requiring high throughput. Here’s a simple change to the default Tomcat logging configuration to implement. It works on all operating systems.

In the file:
$TOMCAT_HOME/conf/logging.properties

Change:
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

to
.handlers = 1catalina.org.apache.juli.FileHandler

REFERENCES:

Sample Tomcat7 setup

There are a few steps that I generally take to setup a new Tomcat server instance, this enables the following:

  • The manager console
  • HTTP compression
  • UTF-8 encoding

Steps:

  1. tomcat-users.xml – add to bottom:

    <role rolename="manager-gui"/>
    <user username="tomcat" password="s3cr3t" roles="manager-gui"/>

  2. server.xml – add compression and URIEncoding, change port if desired:

    <Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" compression="on" URIEncoding="UTF-8" />

  3. server.xml – relocate webapps by adding ../ to appBase

    <Host name="localhost" appBase="../webapps"
    unpackWARs="true" autoDeploy="true">

  4. Restart your server, on Ubuntu use:

    sudo service tomcat7 restart

crossdomain.xml

Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

REFERENCES:

Free website uptime monitoring

Regardless if you host your own websites, or pay to have them hosted elsewhere, up-time, availability and network performance metrics are important to your visiting guests.

Here are two free services that I’ve found useful for monitoring, notification and reporting.

BTW, you can even use these to watch competitors or sites that you frequent.

Cloudflare CDN (Content Delivery Network)

Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.

CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.

Implementation takes only minutes as it requires that you:

  1. create a (free) account,
  2. retrieve your existing DNS values from your current provider,
  3. determine direct vs. CDN “cloud” routing for each subdomain,
  4. change your DNS records to point to the CloudFlare DNS servers

Some additional advantages I’ve seen since implementing:

  • Site remains available in limited capability to users during server outages or upgrades.
  • Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
  • IPv6 dual-stack support

REFERENCES:

X-Download-Options:noopen to download files

There are a couple of steps required to force a browser to save/download content instead of displaying it in the browser window.


X-Download-Options: noopen
X-Content-Type-Options:nosniff
Content-Disposition: attachment; filename=example.txt
Content-Type: text/plain

NOTE: MSIE also supports a poorly documented proprietary META tag…

<meta name="DownloadOptions" content="noopen|nosave" />

REFERENCES:

window.location.reload(true);

While working on legacy apps, you might occasionally find that a developer has written a function to reload the existing page. I’ve found that in many cases, the optional javascript argument is neglected in this case and thus the ‘cached’ copy of the page is presented, often showing stale or invalid data. The solution here is simple, always specify ‘true’ to force the page to be requested from the server.


<script type="text/javascript">
window.location.reload(true);//NOTE: 'true' forces NON-cached copy to be returned
</script>

REFERENCES:

Overriding MSIE’s Friendly Error Message screens

IE overrides several HTTP error status pages but it has a size threshold. Only if the error page send by the server has a large enough body then IE decides it’s meaningful and displays it.

Usually to be safe you should make error pages that are larger then 512 bytes. The threshold varies per HTTP status code. You can look at what your thresholds are currently set to. In IE 5 and greater the settings are stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\ErrorThresholds]

Err Size(bytes):

  • 400 512
  • 403 256
  • 404 512
  • 405 256
  • 406 512
  • 408 512
  • 409 512
  • 410 256
  • 500 512
  • 501 512
  • 505 512

REFERENCES:

RabbitMQ setup on Ubuntu

In my past enterprise experience, I’ve worked a lot with IBM WebSphere MQ, as I’ve evolved to open source, I’ve found RabbitMQ to fill my messaging needs as an implementation of AMPQ. While I’ve added Ubuntu installation instructions here, server and API implementations are available for most programming languages and operating systems.

NEW WAY:

sudo apt-get install rabbitmq-server

OLDER RELEASES:

sudo wget http://www.rabbitmq.com/rabbitmq-signing-key-public.asc

sudo apt-key add rabbitmq-signing-key-public.asc

sudo vim /etc/apt/sources.list.d/rabbit.list

NOTE: this file will probably be empty, just add the following line (for Ubuntu 11.04 and earlier)


deb http://www.rabbitmq.com/debian/ testing main


sudo apt-get update
sudo aptitude install rabbitmq-server

REFERENCES:

HTTP ETag Header

These are useful for some advanced caching behavior, but there are cases where you might find them unnecessary for static files (in particular). Most network analysis tools will call attention to this header value, and while it seems like a trivial amount of bandwidth to send from the server to the client, the real reason for the negative score is more likely related to the behaviors that it causes in the client.

It should be noted that the default value used for the ETag is based upon the ‘inode’ of the file, as such it’s IS problematic in clustered server environments. I’ve shown the correction for this below.

Adding the following to your Apache http.conf file is a start:


# Change ETag to remove the iNode (for multi-server environments)
FileETag MTime Size

#Remove ETag from all static content, this could be done globally without the FilesMatch, but we want better control.
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset ETag
</IfModule>
</FilesMatch>

REFERENCES:

Cheers.