ATG User Experience Performance Tuning

How to improve the page load time and rendering time for your ATG application!

How your users and customers perceive the speed of your site is critical. The faster and more responsive your site appears to them the better experience they have and the more likely they are to make a purchase. There are plenty of studies about page response time and abandonment, so I won’t rehash the “why” of it here.

There are three components that drive how responsive a page feels to an end user:

  1. Primary Page HTML response time
  2. Primary Page DOM parsing time
  3. Secondary Asset load time

The first component is driven by the server’s request processing time (DRP service time), the page’s HTML size, and the speed of the connection between your server and your end user’s computer.

The second component is driven by the size and complexity of the HTML DOM tree.

The third component is driven by the number of secondary assets, such as JavaScript, CSS, images, Flash, etc…, the size of those assets, the speed of the network connection to those assets, and the cache headers of those assets (to avoid having to load them for each page).

So, we have to look at file sizes, DOM complexity, number of files, cache headers, the speed of request handling on the server, and the network speed between the user and the server.

That’s a lot.

So where do we start?

Continue reading

ATG Performance Tuning

ATG performance tuning is not a Black Art. I have over 10 years of experience with ATG, and hopefully I can provide a guide to performance tuning your ATG application.

Improving web application performance is an often overlooked way to cut costs and increase sales. Complex ATG E-Commerce applications in particular are often left untuned due to the scope of the application and typical tight timelines of project cycles. It’s not mysterious voodoo, and it WILL be worth the time you put into it.

Web application performance can be split into two sections:

  1. The End User’s perception of the site performance
  2. The Server’s perception of the site performance

The first section relates to how quickly pages render for the user and how responsive the site feels. The less time the user spends waiting for the page to load and render, the more likely they are to make a purchase/sign-up/or whatever your conversion goal is. Relevant metrics would be page load time, page asset load time, and page render time.

The second section relates to how many users or transactions an application server can support with acceptable response times. Relevant metrics would include requests per second within the context of reasonable CPU load, I/O wait, etc…

Luckily many of the change we end up making to improve the end user’s experience will also reduce the processing and request load on the servers, so there are some inter-dependancies.

I’m going to tackle the two sections of web application performance in two separate blog posts here, and hopefully will show you how to diagnose the poorly performing aspects of your site, figure out the biggest improvements you can make, and implement the changes. While these posts will focus on ATG based applications, much of what I’m going to cover is true for any web site or web application.

—————Posts in this series so far————–

  1. ATG User Experience Performance Tuning
  2. Why Is User Experience Performance So Important?
  3. Improving JSP Serving Time for an ATG Application
  4. Improving Secondary Asset Load Time for an ATG Application
  5. Improving ATG Performance With a Content Delivery Network (CDN)

ATG Cache Header Control Module

Many ATG application server static content, or semi-static content, from within the ATG application’s .war file. It is often much simpler to package CSS, JavaScript, Flash, Images, and other files in your web application than to try to manage them separately and deploy correctly in development and production instances.

It is often desirable to set long cache times for static content and you may also want to ensure that certain other files or URIs are never cached. Unfortunately ATG does not provide a mechanism for tuning the cache headers.

I have created a new ATG Module which allows you to easily adjust cache header times based on mime-types and URIs, including parent directories. You can download it here: DSCacheControl ATG Cache Header Control Module.

I have built and tested it using ATG 7.1 I will be releasing one for ATG 2007.1 in a bit, which may be based on a Servlet Filter instead, but I haven’t decided yet. This one may work on ATG 2007.1, I haven’t been able to test it yet.

It is very simple, with two classes: a pipeline servlet and a custom comparator, and two config files: the pipeline servlet’s configuration and an Initial.properties to start the servlet. The source code is included in the module.

It allows you to control the cache time used to build the cache related response headers based on the requested asset’s mime-type and URI location. It has an order of precedence of a default setting of 0 seconds (do not cache at all), then the mime-type settings are used, and then the URICacheMap is examined to find the most specific entry which is the specific URI or a parent directory. This should allow you to setup basic settings, and override them for specific directories or files as needed.

Here are some example config settings to give you an idea:

mimeTypeCacheMap=image/png=604800, \
image/jpeg=604800, \
image/gif=604800, \
application/x-javascript=604800, \
application/x-Shockwave-Flash=604800, \
flv-application/octet-stream=604800, \
text/html=0, \
text/css=604800

URICacheMap=/myapp/images=2592000, \
/myapp/index.jsp=2342343, \
/myapp/other.jsp=1342342, \
/myapp/images/changing-image.jpg=3600, \
/myapp/huge-static-jsp.jsp=2592000

To install it, simply download the zip file, unzip it, copy the module into your ATG 7.1 root directory and add the module to the list of DYNAMO_MODULES in your environment.sh (or add it using the -m option on the command line when you start ATG). You will likely want to override the default configuration. The .properties file is heavily commented and should be simple to understand. You can edit it within the module if you like, although of course the better approach is to set your cache settings in your application module or in localconfig, depending.

If you try it, please give me your feedback. If you enhance it, please share the code back with me.

13 Steps to peace of mind

If you’re uptight about uptime, if you’re anxious about availability, if you nervously watching Nagios, have I got the program for you. Forget 12 step programs, mine has 13!

First let’s talk load balancing. Load balancing is basically distributing some type of load across multiple servers or resources. For the sake of simplicity, we’ll assume that it’s web requests to web servers that we’re talking about, but it’s all equally applicable to databases, mail servers, or just about any other network accessed computing resource (assuming you can handle the back-end synchronization if required, such as with a database).

There are two primary reasons to load balance:

  1. Capacity: one server may not have enough power or resources to handle all of the requests, so you need to break the load out across multiple servers.
  2. Redundancy: relying on a single server means that if it fails, everything is down. A single point of failure can bring down your critical application. Servers fail; both hardware and software. A blown power supply, bad RAM, a dead NIC, eventually something will go out. No software is 100% bulletproof either. If you have two or more servers handling the load, then even if one fails, the other(s) can take over without your application or users seeing any difficulties.

A load balancer sits between your users (human or machine) and your servers. It typically passes requests through to multiple servers and returns the responses to the end user, acting like a transparent proxy. It can distribute load in many different ways, randomly, round-robin, or in more complex ways. It usually monitors the servers so that if a server dies it is removed from the pool and no user requests are sent there.

Load Balancing Diagram

Continue reading

10MinuteMail.com hit digg.com’s front page last night

It’s filtered down a few pages off the front, but hey, front page of digg.com! Wow! Totally grassroots in about 4 hours. Now it’s on all kinds of little blogs and tech forums and other odd places. Over 100k hits in the last 18 hours. It performs very well. There’s very little cpu hit at all. Go SEAM!

Anyhow, I’m proud. Check it out and let me know what you think!

Digg.com:
“A disposible email service…You can read them, click on links, and even reply to them. The e-mail address will expire after 10 minutes.”

read more | digg story