Using Zeus Traffic Manager as a webserver

Zeus Traffic Manager has lots of great features as a load-balancing proxy for web pages and web apps, and it provides many ways to accelerate your existing web traffic. But have you thought about using Zeus Traffic Manager as a web server, and not just as a proxy?

Read this article to find out how to get rid of your old webservers and simplify your network!

At first, this might not seem worthwhile. After all, there are lots web servers out there. Why switch to Zeus Traffic Manager? However, for many people, the webserver's role has shrunk. Back in the old days, your webserver probably served up static pages, and generated dynamic content via an API like CGI, FastCGI, ISAPI or mod_php.

Nowadays, it's becoming much more common for dynamic content to be generated via its own dedicated app server, like WebSphere, JBoss, BEA WebLogic, Glassfish, and so on. Your webserver still serves the static content, and the dynamic pages are proxied to the app server via HTTP. This means that your webserver is left with two simple tasks: 1) Delivering static web pages, and 2) Sending HTTP onto the app server:

Now, Zeus Traffic Manager is great at proxying HTTP. If it could also serve static web pages, then you could throw out your web servers and simplify your server setup. Fewer machines, less hassle! So, how can Zeus Traffic Manager (ZXTM) deliver static web pages?

Simple case: a web server in TrafficScript

TrafficScript has an easy function to send back web pages: http.sendResponse(). The content can come directly from the Zeus Traffic Manager resource directory. Here's a simple TrafficScript web server:

# We will serve static web pages for all content under this directory
$static = "/static/";
 
$page = http.getPath();
if( !string.startsWith( $page, $static )) break;
 
# Look for the file in Zeus Traffic Manager's resources
$page = string.skip( $page,string.length( $static ));
if( resource.exists( $page )) {
   # Page found!
   http.sendResponse( 200, "text/html", resource.get( $page ), "" );
} else {
   # Page not found, send an error back
   http.sendResponse( 404, "text/html", "Not found", "" );
}

After adding this rule to a virtual server, you just need to upload your web pages via the Catalogs->Extra Files. They will then be delivered by Zeus Traffic Manager. It will probably be as fast, if not faster, than whatever webserver you currently use. Job done!

For another example of this approach, take a look at the Error Handing article that describes how to serve back an error page, including images and other dependencies, when all your webservers have failed.

However, this approach is a bit too simple. For a start, it is just delivering HTML files. What about images / video? What about directory listings? Also, it can be a pain to have to upload your content to Zeus Traffic Manager each time it changes. On top of that, the resource files are loaded into memory, so if you are serving large files then it will eat a lot of RAM. Wouldn't it be better for Zeus Traffic Manager to serve webpages from a directory on disk?

An improved web server - using Java

We can improve upon the simple TrafficScript web server by using a Java Extension to generate the web pages. The Java Extension can load the files from disk. It can also do all the other things that a web server should do - sending the right MIME-type for the files, displaying directory listings, handling huge web sites, etc.

At its core, generating a web page in a Java Extension is trivial - the following code snippet shows the minimal work needed. Note that the code isn't even Zeus Traffic Manager-specific:

public void doGet( HttpServletRequest req, HttpServletResponse res )
   throws IOException
{
   String dr = "/docroot";
   String uri = req.getRequestURI();
   File file = new File( dr + uri ); // n.b. should be checking for .. in the path!
   res.setStatus( 200 );
   OutputStream out = res.getOutputStream();
   InputStream in = new FileInputStream( file );
   byte[] buffer = new byte[ 4096 ];
   for(;;) {
      int r = in.read( buffer );
      if( r < 0 ) break;
      out.write( buffer, 0, r );
   }
   in.close();
   out.close();
}

Complete source for the Java webserver is available here to download,or just download the compiled class, ready to upload to Zeus Traffic Manager. The full code contains numerous improvements such as a configurable document root, MIME-typing, proper HTTP date headers, proper (secure!) URL parsing, error pages for missing files, and a rudimentary directory listing page.

To make use of this webserver, go to the Catalogs->Java page in the Zeus Traffic Manager UI, and upload the class file. Then click on the 'Webserver' Java extension, and add a new parameter to it, called 'docroot'. The value for this parameter should be the document root for your website, i.e. where the content will be found.

Next, the Java extension needs to be invoked for your virtual server - but only for the static content. Create a new TrafficScript rule:

# Only run the Java Webserver for static content
if( string.startsWith( http.getPath(), "/static" )) {
   java.run( "Webserver" );
}

Now, when a request to your virtual server such as /static/logo.png arrives, it will be delivered via the Java Extension. The extension will look for a file on disk called /docroot/static/logo.png and if found, it will deliver it back to the user. Voilà - a fully-functioning webserver!

Optimizing for Performance

There's no point putting a webserver in Zeus Traffic Manager unless it is fast. Surely using Java to deliver a static web page is going to be very slow, especially a simple servlet that loads files off disk on every request?

Well, it certainly isn't as fast as a standalone webserver - but that can be fixed. Static webpages are cacheable, so to improve performance, it makes sense to enable Zeus Traffic Manager's web cache feature. With Zeus Traffic Manager delivering the pages from its cache, the static pages will be exceedingly fast.

There is one complication to enabling the cache - it is not possible to just switch it on for the virtual server and let it go. This is because Zeus Traffic Manager will decide whether or not to send a page from its cache after the request rules have run, but it is in these request rules that the Java Extension generates the response and sends it back.

The elegant solution is to create a virtual server in Zeus Traffic Manager specifically to run the Java Webserver Extension. Then, your primary Virtual Server can send traffic to the internal virtual server when appropriate, and it can cache the results as normal:

The primary Virtual Server decides whether to direct traffic to the back-end servers, or to the internal web server

Follow these steps to configure Zeus Traffic Manager:

1. Create a new HTTP virtual server - this will be used to run the Java Extension. Configure the virtual server to listen on localhost only, as it need not be reachable from anywhere else.

2. Add a TrafficScript rule to this virtual server to make it run the Java Extension. The rule can just be:

   java.run( "Webserver" );

   since only static web pages will be served from it.

3. Create a pool called 'Internal Web Server' that will direct traffic to this new virtual server. The pool should contain the node localhost:[port].

4. Change the TrafficScript rule on the original virtual server to:

   # Use the internal web server for static content
   if( string.startsWith( http.getPath(), "/static" )) {
      pool.use( "Internal Web Server" );
   }

5. Enable the web cache on the original virtual server.

Now, all traffic goes to the original virtual server as before. Static pages are directed to the internal web server, and the content from that will be cached. With this configuration, Zeus Traffic Manager should be able to serve web pages as quickly as needed.

How fast will it go? Well, apart from the first request for a static page, the pages will come directly out of Zeus Traffic Manager's web cache. Benchmarks of Zeus Traffic Manager on inexpensive hardware show that it can serve up to 400,000 pages a second from the cache. That should be fast enough!

Don't forget that all the other Zeus Traffic Manager features like content compression, logging, rate-shaping, auto MIME-typing, SSL encryption and so on can all be used with the new internal web server. You can even use response rules to alter the static pages as they are sent out.

Now, time to throw your web servers away?

Ben [Zeus Dev Team] 27 April 2009