1. Download Microsoft Web Platform Installer, and install it.

2. Run Web Platform Installer and click “Options”.

3. Add Helicon Zoo feed into “Display additional scenarios” field: http://www.helicontech.com/zoo/feed Select “IIS” as a target web server.

A new tab named “Zoo” should appear on the main page of Platform Installer.

4. Go to Zoo → Applications and add OSQA, then click install.

5. Accept license agreements

Web Paltfrom Installer will start downloading and installing required components, which include Python 2.7.2, Django 1.3, Helicon Zoo Module, MySQL and OSQA itself.

6.  Setup new web-site dialog will appear. Fill it with your site specific values.

7.  Database dialog will open. Fill it to create new or use existing MySQL database.

Default administrator user name for MySQL is ‘root’ and default password is empty.

Installation will configure database and run migration scripts, you can now launch web site by clicking on a link:

Congratulations! You have finished installation and may start using OSQA on your Windows server with Microsoft IIS in production:

1. Download Microsoft Web Platform Installer, and install it.

2. Run Web Platform Installer and click “Options”.

3. Add Helicon Zoo feed into “Display additional scenarios” field: http://www.helicontech.com/zoo/feed Select “IIS” as a target web server.

A new tab named “Zoo” should appear on the main page of Platform Installer.

4. Go to Zoo → Applications and add Redmine, then click install.

This will automatically download and install all required components, including Ruby 1.8.7, Rails 2.3, Helicon Zoo Module and Redmine itself.

5. Setup new web-site dialog will appear. Fill it with your server specific values.

6. Go to the /admin/ folder on this web-site. Use login “admin” and password “admin” to enter Redmine Administration panel.

Custom database

Redmine supports multiple database engines. By default SQLite is installed, however there are example configuration files for MySQL and PostgreSQL within “config” folder of Redmine application. If you wish to use MySQL, for an instance, take “database.yml.mysql” file; name it as “database.yml” and alter according to your MySQL database settings. Then restart IIS application which contains your Redmine application. All required database migrations will be executed automatically by deploy.rb script.

That’s it, enjoy!

In this article we are going to address basic question which might occur in minds of green web-programmers and those who is going to dive into Node.js learning, namely:

• how to install Node.js developer environment of your PC;
• how to code;
• how to debug;
• how to deploy what you’ve done on remote server.

And the performance tests at the end of the article will try answer a reasonable question “Why would I need to learn Node.js.”
So, let’s start…

Node.js is an event-oriented Javascript-based framework for development of web applications. The core concept is that nothing gets blocked during code execution – operations waiting for data transfer, data input, connection establishment or anything else are not present. Everything is based on events, which occur at the moment synchronous operations are waiting for. This sometimes leads to dramatic—dozens of times—performance boost in comparison with old sync systems. With the release of version 0.6.0 of November 2011 Node.js assembly for Windows in announced stable.

Installing working environment

To begin it’s necessary to download and install Web Platform Installer, run it, click Options and put Helicon Zoo Feed link http://www.helicontech.com/zoo/feed/ into “Display additional scenarios” field:

This adds Zoo tab in Web Platform Installer:

Installing Node.js

Under Zoo -> Engines there’s a list of all available web engines, including Node.js. However, we recommend opting for Node.js Package which incorporates not only Node.js itself but also several highly useful modules. So, got to Zoo -> Packages -> Node.js Hosting Package and do Add, Install.

To see all currently supported web frameworks and applications visit Helicon Zoo Gallery. After you agree to the license agreements, it starts downloading and installing IIS (if not yet there), Helicon Zoo Module and node.exe for Windows.

An important system component is Node Package Manager (npm) used for installation of additional modules. Starting from version 0.6.5 of Node.js Node Package Manager declared stable and now is included into Node.js Hosting Package.

Installing WebMatrix templates

Now Node.js is installed and to start doing applications for it it’s reasonable to use WebMatrix templates. These templates simplify creation of blank draft apps which might be used for further development.
To install them follow: Zoo -> Packages -> WebMatrix Templates

If you don’t have WebMatrix – not to worry – it will be downloaded and installed automatically together with installation of templates. After the installation run WebMatrix and choose «Site from Template»:

As you can see, Node.js is not the only framework favoring from WebMatrix templates.

If you follow the URL of the newly created Node.js Site or press Run, you get common «Hello, World!» page.

By default the new site includes framework express for easy web-apps creation. The framework and its dependencies reside in node_modules folder under the site root which is good for deployment of the app on remote server.

The folder “public” is used to store static files. Any file put into this folder will be processed directly by IIS as static, not evoking Node.js. This is especially important to avoid accidental execution of client *.js files on the server.

web.config file contains URL Rewrite rules for static content. Initially every request is checked against the content of public folder (i.e. whether it’s static). This is beneficial for some web apps which mix static and dynamic resources in one folder (often root). If your app is not doing so, you can delete Microsoft URL Rewrite rules from web.config and refer to static files by explicitly specifying public folder.

Additionally, web.config includes configuration directives required for launch of Node.js and Helicon Zoo Module on that site.

Composing the first app

One of the advantages of Node.js is that JavaScript is a popular language widely used in web development. It means you won’t have problems choosing the editor. Free WebMatrix editor is ok to start with.

To illustrate capabilities of asynchronous web frameworks most write a chat. So, the most known demo-app for Node.js is a chat http://chat.nodejs.org/, its source code is available for examination.

We’ve also decided to make a chat – very primitive one – with no users, no sessions, no scrolls and message editing. It can only transmit asynchronous messages to show how long-polling works.

We’ll make use of previously-created Node.js Site. We need to edit server.js and index.html.

Here’s the source code for server.js:

var express = require('express');
var callbacks = [];

// Sends messages to clients
function appendMessage(message){
  var resp = {messages: [message]};
  while (callbacks.length > 0) {
    callbacks.shift()(resp);
  }
}

// Creation of express server
var app = module.exports = express.createServer();
app.use(express.bodyParser());

// Simply respond with index.html
app.get('/', function(req, res){
    res.sendfile('index.html');
});

// Process messages from client
app.post('/send', function(req, res){
  var message = {
    nickname: req.param('nickname', 'Anonymous'),
    text: req.param('text', '')
  };
  appendMessage(message);
  res.json({status: 'ok'});
});

// Wait for new messages
app.get('/recv', function(req, res){
  callbacks.push(function(message){
    res.json(message);
  });
});

// Listen to the port
app.listen(process.env.PORT);

and index.html

<html>
<head>
<title>Node.js Zoo Chat</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">

// Initialization after page load
$(document).ready(function(){
  $('form#send').submit(onSend);
  longPoll();
  $('#nickname').focus();
});

// Send message on pressing Submit
function onSend(eventData){
  eventData.preventDefault();
  var msgArr = $(this).serializeArray();
  var message = {
    nickname : msgArr[0].value,
    text : msgArr[1].value
  };
  $.post('/send', message, function (data){
    $('#text').val('').focus();
  },
  'json');
}

// Called when new message is available
function longPoll(data){
  if (data && data.messages) {
    for (var i = 0; i < data.messages.length; i++) {
      var message = data.messages[i];
      $('<p><b>'+message.nickname+':</b><span>'+message.text+'</span></p>').hide().prependTo('#messages').slideDown();
    }
  }

  // message processed, wait for new messages
  $.ajax({
    cache: false,
    type: "GET",
    url: "/recv",
    success: function(data){
       longPoll(data);
    }
  });
}
</script>
</head>
<body>
<h1>Node.js Zoo Chat</h1>
<form action="/send" method="post" id="send">
    <label for="nickname">Nickname:</label> <input name="nickname" size="10" id="nickname" />
    <label for="text">Message:</label> <input name="text" size="40" id="text" />
    <input type="submit">
</form>
<div id="messages"></div>
</body>
</html>

To apply changes press Restart and then Run:

Now we can make sure the chat works by running it in two browsers:

Installing modules

The flexibility and usability of each web framework may probably be defined by availability of extra modules and applicability of third-party technologies. At present Node Package Manager declared stable for Windows, so you ca use it safely for modules installations. NPM is included in Node.js Hosting Package and we have plans to include it into Node.js engine installation itself very soon – just as new Node.js MSI installer will be applicable to use in Helicon Zoo repository. And there’s one trick to remember – by default npm installs modules to node_modules folder under the folder it was invoked from. This is good for further application deployment on remote server as all required modules are included into application folder itself. Thus, to install module for site, go to the site root and execute:

C:\>cd "C:\My Web Sites\Node.js Site"

C:\My Web Sites\Node.js Site>C:\node\npm.cmd install mongodb

npm WARN nodeunit@0.5.1 package.json: bugs['web'] should probably be bugs['url']
> mongodb@0.9.7-1.4 install C:\My Web Sites\Node.js\node_modules\mongodb
> node install.js
================================================================================
=                                                                              =
=  To install with C++ bson parser do <npm install mongodb --mongodb:native>   =
=                                                                              =
================================================================================
mongodb@0.9.7-1.4 ./node_modules/mongodb

Another thing worth mentioning is that no all existing modules work for Windows. E.g. the perfect node-sync library won’t work for Windows. This library helps avoid monstrous callbacks paradigm without losing Node.js asynchronous nature, but it relies on node-fibers, which do not work on Windows. Hopes are that in future fibers will be implemented directly into Node.js.

Nevertheless, most modules are fully operational on Windows.

CoffeeScript

If you start working on a more or less complex Node.js project, sooner or later you’ll come to a conclusion that JavaScript is not that friendly. Tons of braces, loads of unnecessary constructions – all that stuff doesn’t add to code readability and makes code management more complicated. Luckily, you are not the first one to notice that, so the problem is already solved. There are many derivative languages based on JavaScript or extending it. Here’s a short list FYI: http://altjs.org/

We take CoffeeScript as the trendiest for now. Code written with CoffeeScript is simple and easy to read. This code is then compiled into original JavaScript and executed. Moreover, JavaScript code may be converted into CoffeeScript. For example, server.js script from our chat in CoffeeScript becomes this:

express = require("express")
callbacks = []

// Sends messages to clients
appendMessage = (message) ->
  resp = messages: [ message ]
  callbacks.shift() resp  while callbacks.length > 0

// Creation of express server
app = module.exports = express.createServer()
app.use express.bodyParser()

// Simply respond with index.html
app.get "/", (req, res) ->
  res.sendfile "index.html"

// Process messages from client
app.post "/send", (req, res) ->
  message =
    nickname: req.param("nickname", "Anonymous")
    text: req.param("text", "")

  appendMessage message
  res.json status: "ok"

// Wait for new messages
app.get "/recv", (req, res) ->
  callbacks.push (message) ->
    res.json message

// Listen to the port
app.listen process.env.PORT

Learn more about CoffeeScript: http://jashkenas.github.com/coffee-script/
To install CoffeeScript run: C:\node\npm.cmd install coffe-script

Debugging Node.js-apps

There’s a good tool for Node.js apps debugging — node-inspector. It is already included into node_modules folder in template of Node.js-site. node-inspector works as follows:

• application to be debugged in run in debug-mode (execute node.exe with –debug or –debug-brk parameter);
• node-inspector, being also a web-app, is launched;
• these 2 apps communicate via WebSocket protocol to share debug information;
• page with the application being debugged is opened in browser;
• webkit-compatible browser opens node-inspector interface with debug info; its interface resembles that of Web Inspector in Google Chrome or Safari.

In root folder of template-based node.js-site there’s start_debug.cmd file which runs debugging for current app and opens pages in the browser for debugging.

This is how debugger looks in the browser:

Deploying on server

Now we have an app and want to put in online. What we need is a server, and now putting together Windows server and Node.js is easy as never before. We only need to go through several steps we did at the beginning of the article (which we used to deploy working environment). Namely: install Microsoft Web Platform Installer, add Helicon Zoo feed into it and set up Node.js Hosting Package from Zoo repository. Done – server is ready to run our app. Server platforms supported include Windows 2008 and 2008 R2, x86 and x64.

What needs to be done next is create blank web-site on the server using IIS or hosting panel (if we are creating our own hosting) and copy the app into the site with FTP or WebDeploy. In case of WebDeploy all necessary permissions for the folders will be assigned. One can also use Git or any other version control system, but that goes beyond the scope of this article.

Initially, Helicon Zoo Module was being developed for configuration of hosting solutions. And all applications within Zoo are separate and do not interfere. The module itself with default settings operates in automatic mode creating one worker process, when the load is low, or bearing new workers (up to the number of processor cores) to ensure maximum performance when the load goes up.

Helicon Zoo adopts the concept of engines and applications. Engines define what to run and how, using which protocol and port, min and max number of workers allowed and other general settings, which are specified globally in applicationHost.config. Then under the site you can create an application relying on a particular engine and pass all parameters required for its flawless operation. This helps isolate hosting administrator work from clients and clients from each other.

Node.js performance testing

Testing server characteristics: Core 2 Quad 2.4 GHz, 8 Gb RAM, 1Gb LAN. For load generation we used more powerful machine and Apache Benchmark command «ab.exe -n 100000 -c 100 –k». To test Apache and Nginx we took Ubuntu 11.04 Server x64. IIS 7 tests ran on Windows Server 2008 R2. Nothing virtual — 100% hardware.

We’ve conducted 3 tests. In the first one Node.js was supposed to output current time in high resolution. Time was chosen to be sure responses didn’t come from cache. Second test implied reading from MySQL database, third one — writing to DB.

Here are the results (values on the graph mean requests per second):

Impressive, isn’t it? Time to explain what these tests measure. It’s not entirely correct to call them performance tests as we do not compare different processors. While processor may have performance, web server measurement unit is quite the contrary — how much processor time it takes to process one request.

The first test measures raw expenses on request processing for each web-server and their ability to use processor resources. There’s no way this or that set of technologies can respond faster on this processor. Nginx on Windows was far behind on this test because on this system Nginx opens new connection to back-end upon each request. While Apache on Windows surprised with connection pooling and true threads.

The second and third test show how web-server expenses grow with the “weight” of request. However, they are influenced by a number of other factors, such as performance of file system, DB drivers and the DB itself. Out of curiosity we’ve tested the joint Windows + Zoo + MongoDB to see the difference with MySQL. And it gave 6793 rps for reading and 2906 rps for writing. Writing speed is truly amazing.

Another interesting fact is that software and hardware used in these tests is absolutely the same as in Django tests in this article. So their results may be compared. Undoubtedly Node.js scripts are much more light-weight, we didn’t use templates, ORM etc,, but anyway it’s worth thinking about.

Responding to readers’ requests we are posting detailed ab graphs. We’ve re-done the first test with simple time output, ‘case it most verbosely depicts web server operation. Config files and js scripts being tested may be downloaded from here. There are only includes, everything else left by default. Horizontal axis shows requests, vertical one — response time in milliseconds.

Windows, IIS7 + Zoo, “time output”:

Ubuntu, Apache, “time output”:

Ubuntu, Nginx, “time output”:

Summing up

I believe that Node.js is a rather promising trend. It boasts great performance and flexibility. What is especially pleasing is that it’s equally good on both Unix and Windows and uses relevant technological solutions for each system which the tests vividly prove.

Support of Erlang and Java in Helicon Zoo is on the way. It will be of interest to compare performance of these technologies as well. For now Node.js is an unquestionable leader in performance among supported frameworks.

Introducing Helicon Zoo – a repository of popular web-frameworks for Microsoft IIS. It bases on Microsoft Web Platform Installer (WebPI) technology to deploy apps. WebPI also handles different dependencies and takes care of installation of necessary components, such as Python, Django, various database drivers and modules. And, of course, Helicon Zoo itself which sticks it all to MS IIS 7.

How to use

Web development process implies use of two relatively independent environments – development and production. Helicon Zoo may be used in production as well as on developer’s machine, or in both places. In either case the sequence of actions might be:

To start, you need to download Web Platform Installer from Microsoft website (http://www.microsoft.com/web/downloads/platform.aspx) and install it. WebPI already includes wide range of frameworks and applications for IIS like PHP, ASP.NET, WordPress, Drupal, phpBB. To launch Helicon Zoo add new feed to WebPI:

• Run WebPI and click Options
  
• In «Display additional scenarios» box put http://www.helicontech.com/zoo/feed and click Add feed
  

If you now go to Zoo, Applications (in WebPI interface) you’ll find some new apps: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project:

Blank Django Project is the simplest “Hello, World!” app used to set up all dependencies needed for Django-app to run and empty Django-project itself. For installation press “Add” and “Install”; then you’ll be shown the list of dependencies:

To accept licenses and start downloading and installing the project press “I Accept”. When done, the newly-installed project can be run by clicking “Launch application in browser”:

This screen symbolizes that Python, Django and the rest of things needed to run the apps were successfully installed on your PC. Now, if it’s a dev environment, you can start creating based on this empty “Hello World” app. After you make some changes to the app, you may upload it to production server with all files, folders, necessarily web.config, and if Blank Django Project was previously installed on the server (regardless on the destination folder as only its dependencies matter), the app is going to work. Every time you upload changes to the server restart Application Pool. This is needed for Django (and Rails) only, other frameworks probably won’t need it. Upon restart automatic data migration will occur – manage.py syncdb. Owing to this fact solution may be used on shared hostings where the user can’t access console.

Using WebMatrix

Another way to go is to use WebMatrix for development. Instead of installing “Blank Django Project” go to Zoo->Packages and install “WebMatrix Templates” and “Python Hosting Package”.

After that run WebMatrix and create new application from template. You will be proposed number of templates to choose from. Please select “Django site” and create it.

Then to deploy your web site to a remote IIS server “Python Hosting Package” has to be installed on this server to run Django applications.

Under the hood

Helicon Zoo core is represented by native IIS module acting as a bridge between IIS web-server and frameworks using Ruby, Python, Perl etc. the module makes use of FastCGI protocol which is recognized as quick and accurate means for interaction between web-apps and web-server. This interaction is asynchronous and uses I/O Completion Port technology. For transport Zoo uses either named pipes or TCP-sockets. Web-servers supported include IIS 7, IIS 7.5 and IIS Express.

Basic Helicon Zoo configuration is stored in <heliconZooServer> section of applicationHost.config. This section includes descriptions of all FastCGI-drivers to be operated via Zoo. Here’s an example of driver description for running Python wsgi-apps (Django-apps in particular), zoofcgi.py is a worker written in Python that provides transport through named pipes:

<engine name="python.2.7.pipe"
     fullPath="c:\python27\python.exe"
     arguments="-O %SystemDrive%\Zoo\Workers\python\zoofcgi.py"
     transport="pipe" />

Web.config

Responsible for configuration of web apps working through Zoo is web.config file. Following is the example configuration of Django-app to work in 32-bit pool:

<?xml version="1.0" encoding="UTF-8"?>
 <configuration>
  <system.webServer>
   <heliconZoo>
    <application name="django.project.x86" >
     <environmentVariables>
      <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" />
      <add name="DJANGO_SETTINGS_MODULE" value="settings" />
          <add name="DEPLOY_FILE" value="deploy.py" />
          <add name="DEPLOY_LOG" value="log\deploy.log" />
     </environmentVariables>
    </application>
   </heliconZoo>
   <handlers>
     <add name="django.project.x86"
                scriptProcessor="python.2.7.pipe"  path="*" verb="*"
                modules="HeliconZoo_x86" preCondition="bitness32"
                resourceType="Unspecified" requireAccess="Script" />
    </handlers>
  </system.webServer>
 </configuration>

Some important comments on the above config:

• scriptProcess="python.2.7.pipe" is a reference to FastCGI-drived defined in applicationHost.config;
• PYTHONPATH environment variable contains a path where Python looks for its modules; in or case we are adding a path to our Django-app into PYTHONPATH;
• DJANGO_SETTINGS_MODULE environment variable storing the path to Python configuration file settings.py for Django-app, e.g. ‘mysite.settings’
• ‘DEPLOY_FILE’ environment variable contains the path to the file within the app which will be run before the first request to the app after restart of IIS-app. This file may be used for DB synchronization, for example: ‘manage.py syncdb –noinput’;
• ‘DEPLOY_LOG’ environment variable contains the path to the file within the app which is the destination for debugging info generated by DEPLOY_FILE command. The folder containing this file must be granted Write permissions for the user running this IIS-app (usually it’s IIS_IUSRS group).

Static content

Django framework is not suitable for fast and safe processing of static files (images, scripts, css). Statics must be processed directly by web-server. To do so all static files must be stacked in one folder and Django request handler for this folder is then switched off like this:

<?xml version="1.0" encoding="UTF-8"?>
 <configuration>
  <system.webServer>
   <handlers>
    <remove name="django.project.x86" />
   </handlers>
  </system.webServer>
 </configuration>

Sample Django-project for IIS 7

Let’s have a Django-project consisting of 3 apps:

• site — the site itself with templates, statics, urls.py nad settings.py
• blog
• store

Static files located in site/media are available in the /media/ virtual folder (i.e. MEDIA_URL=’/media/’)

Having installed Blank Django Project in the root of the site and having copied our django-project, we’ll get the following structure:

/media/ is a virtual folder pointing at site/media; Zoo module is switched off for this folder as mentioned above. PYTHONPATH in root web.config points at site root and DJANGO_SETTINGS_MODULE is set to ‘site.settings’:

...
  <heliconZoo>
    <application name="django.project.x86" >
     <environmentVariables>
      <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" />
      <add name="DJANGO_SETTINGS_MODULE" value="site.settings" />
     </environmentVariables>
    </application>
   </heliconZoo>
...

Performance

And now performance test for dessert. Testing machine acting as server was Core 2 Quad 2.4 GHz, 8 Gb RAM, Gigabit LAN. To generate load we used more powerful PC with Apache Benchmark. To measure Apache and Nginx performance Ubunthu 11.04 Server x64 was used. IIS 7 tests ran on Windows Server 2008 R2. No virtual machines – only bare hardware. As transport on Nginx we used the most advanced uwsgi, as well as wsgi and fast_cgi for comparison. On IIS 7 we’ve also compared with PyISAPIе.

There where two Django scripts created as testing pages. The first one outputs current time in high resolution; this is done to ensure pages are not taken from cache. The second one does the same but previously saves the result into database. It’s all done using templates in order to apply real Django infrastructure; DB used is MySQL. All settings were left default as the task was to test the most common configurations. Here are results (in requests per second):

No surprises here as Python performance on Windows may be slower than Ubunthu version. Taking this into consideration Helicon Zoo transport performance should be really high. Uwsgi is ahead probably due to closer integration with Django.

The results for the second script are not that smooth. Why Nginx + fcgi + MySQL showed only 175 requests per second remains unknown. MySQL on Windows score is also frustrating, although on shared hosting the problem might not be that critical. The thing is that performance drops due to internal MySQL locks, while the server is not even loaded for 20% while generating these 104 requests per seocnd. It’s reasonable to assume that by increasing number of sites on the server and consequently the number of DBs, if they do not interlock with each other, the total server performance will be acceptable.

Thus we decided to add MS SQL Express into the tests. The result was easy to explain with Python and its database driver being the bottleneck, though in general the picture is quite promising. Unfortunately PyISAPIe was unable to work with MS SQL Express and was excluded from tests.

It is worth to mention the ability of IIS 7 to handle great number of connections. IIS 7 + Helicon Zoo easily held thousands of concurrent connections, we simply didn’t have testing powers to generate enough connections to trigger any problems in this test. Ubuntu with default settings started throwing connection failures when the number of connections increased. Moreover, Apache appeared to be greedy for memory. During the test with the number of connections going up Apache swallowed about 3 GB in 20 seconds.

Resume

Suggested solution proved stable and efficient. It will perfectly fit development environment as well as production. Advantageous is possibility of using Helicon Zoo by different Windows shared hosting providers to offer Django services to their clients. Hope is that with the growth number of Django servers on Windows Python developers will pay more attention to code debugging and optimization for Windows platform. And the army of existing Windows-developers can also contribute to current open-source projects.

How it works

Helicon Zoo utilizes Microsoft Web Platform Installer (WebPI) to make installation of web frameworks and all required dependencies easy and smooth. At first, you need to download and install WebPI from Microsoft web site here. This is a great tool that is already packed with many ASP.NET and PHP applications and dependencies to install a whole technology stack on your server. And the greatest thing about WebPI is that it can be extended by adding custom repositories. So copy this link - http://www.helicontech.com/zoo/feed/, open WebPI options

put it into the Display additional scenarios field and click Add feed.

Now if you select Applications, Tools at the bottom of the list, you will find new applications: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project

These are all empty “Hello World!” applications used to install all required dependencies which you can stuff with your code later.

So let’s choose Blank Django Project, click Add and Install.  This will create new IIS application with pre-defined configuration. After download and installation are completed you can use Launch application in browser link:

What’s inside

The core of Helicon Zoo is a native IIS 7 (or IIS Express) module that provides FastCGI support. This module differs from Microsoft FCGI module generally developed to provide PHP support for IIS. Helicon Zoo Module is built using super capacitive asynchronous  I/O Completion Port technology. It supports Pipe and TCP transports and additional level of configuration to run many different FastCGI-enabled frameworks. These includes flup tor Python, Rack for Ruby on Rails, FCGI and Plack for Perl and Mojolicious.

The core configuration of Helicon Zoo Module is located in the <heliconZooServer> section of applicationHost.config file. This section defines all FastCGI engines that will work with Zoo. Here is an example of Django FastCGI engine definition using pipe transport; zoofcgi.py is our Python worker with pipe transport support:

<engine name="python.2.7.pipe"
    fullPath="c:\python27\python.exe"
    arguments="-O %SystemDrive%\Zoo\Workers\python\zoofcgi.py"
    transport="pipe" />

How to deploy Django projects

Helicon Zoo offers simple way to deploy your Django applications on the server or test machine. First you install Blank Django Project in desired location using Web Platform Installer, then you overwrite this project content with your project files and set up deployment into this forlder. Blank Django Project installs all required dependencies on target machine and puts web.config (the only file needed for your application) in the root directory of application.

Web.config

Configuration of Zoo-powered applications is done with web.config file. Here is an example of such file to configure Django application for 32-bit.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <heliconZoo>
   <application name="django.project.x86" >
    <environmentVariables>
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="settings" />
    </environmentVariables>
   </application>
  </heliconZoo>
  <handlers>
   <add name="django.project.x86"
       scriptProcessor="python.2.7.pipe"  path="*" verb="*"
       modules="HeliconZoo_x86" preCondition="bitness32"
       resourceType="Unspecified" requireAccess="Script" />
  </handlers>
 </system.webServer>
</configuration>

Several important things are defined here:

• scriptProcess="python.2.7.pipe" — a reference to FastCGI engine defined in the applicationHost.config;
• environment variable PYTHONPATH — a path where Python will check to load modules.  Here path to this IIS application is appended to allow Python to load additional modules directly from the directory of your application without installing them globally in the system.
• environment variable DJANGO_SETTINGS_MODULE — a Python path to the configuration file settings.py of your Django project, for example ‘mysite.settings’.

Static content

It is recommended to serve static content omitting Django to save processor time and increase performance. You can easily do this by putting all static files into a directory with the following web.config in it. This will disable Django module in directory:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <handlers>
   <remove name="django.project.x86" />
  </handlers>
 </system.webServer>
</configuration>

Django configuration example

Let’s assume our Django project consists of three applications:

• site — a site itself with pages templates, static files, urls.py and settings.py;
• blog;
• store.

Static files are located in site/media and are available as /media/ virtual directory (i.e. MEDIA_URL='/media/').

After we install Blank Django Project in the root of web site and copy our Django application project in it we will have the following directory structure:

/media/ — is a virtual directory which is mapped to site/media and Django is disabled there using web.config file example above. In the root web.config PYTHONPATH points to the site root directory and DJANGO_SETTINGS_MODULE is set to site.settings:

 ...
 <heliconZoo>
   <application name="django.project.x86" >
    <environmentVariables>
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="site.settings" />
    </environmentVariables>
   </application>
  </heliconZoo>
...

That’s all!
Sincerely, Helicon Tech team.

The steps to be accomplished are:

• create a table in the database to store the download counters for the products;
• create an .htaccess in Helicon Ape which will make records into the table upon each download with the help of mod_dbd module;
• create a simple aspx-page to show downloads statictics.

Preconditions

In the root of your site you have a downloads folder containing files for download (e.g., AudioCoder.msi, AudioDecoder.msi, AdditionalCodes.zip).
You have Helicon Ape installed on your Windows Server 2008 (IIS7).
You have SQL Server that will store the DB with downloads statistics.

Table for storing statistics

Run Microsoft SQL Server Management Studio and connect to your SQL server.

Right click on ‘Databases’, select ‘Create Database’, enter database name (for example ‘DownloadsCounter’) and click ‘OK’.

Now we’ll create the table itself:
Unfold the DownloadsCounter in Object Explorer, right click on ‘Tables’ and select ‘New Table…’. Name the table ‘Downloads’ and add 4 fields: id (int), moment (datetime), filename (nvarchar(50)) and ipaddress (nvarchar(50)) as shown on the pic below. You can find sql script to create table in attached DownloadsCounterExample.zip.

Done with the table!

mod_dbd configuration

Start Helicon Ape Manager, select your site from the tree and click on ‘downloads’ folder. Now write the following config in .htaccess on the right.

The config instructs mod_dbd to connect to DB, catches data from request (filename and client ip-address) and writes them into the DB.

# Helicon Ape version 3.0.0.59

# Connection settings
DBDriver mssql
DBDParams "Data Source=db2003\MSSQLSERVER2008;Initial Catalog=DownloadsCounter;\
           User ID=sa;Password=123123"

# Save Filename (for .msi & .zip files only)
SetEnvIfNoCase REQUEST_URI ^/downloads/(.+\.(?:msi|zip))$ FileNameENV=$1
SetEnvIfNoCase REMOTE_ADDR ^(.*)$ IpAddrENV=$1

# Sql query to save download event
DBDPrepareSQL "INSERT INTO DownloadsCounter.dbo.Downloads\
    (moment, filename, ipaddress)\
    VALUES (\
        GETDATE(),\
        '%{FileNameENV}e',\
        '%{IpAddrENV}e'\
    )\
" InsertDownload

# Execute sql query if request uri is .msi or .zip file
SetEnvIf request_uri \.(?:msi|zip)$ dbd_execute=InsertDownload

# limit access to statistics page to localhost only
<Files stat.aspx>
Order Deny,Allow
Deny from all
Allow from ::1 127.0.0.1 localhost
</Files>

Save your .htaccess and try to download something from the browser. If you now throw a glimpse at the ‘downloads’ table in SQL Server Management Studio, you’ll see the records appearing in it:

How it works?

Helicon Ape module is processing all requests coming to /downloads/ folder. If .zip or .msi file is requested, Ape memorizes the filename (FileNameENV) and client IP (IpAddrEnv), from which the file was requested, and inserts these data into the table by means of SQL query.

Statistics viewer

The archive attached to the article includes stat.aspx which does a very simple task—shows records from ‘downloads’ table.

Of course, that’s not the sort of viewer you need, as it must be capable of showing statistics by days, months, products etc. But designing a real-life solution is beyond the scope of this article, so feel free to advance stat.aspx by yourself.

Resulting archive

Below is the archive DownloadsCounterExample.zip containing all files from this article. To do some testing just unzip it into the root of your site and replace the database password from ’123123′ to the one you have in both .htaccess and web.config.

DownloadsCounterExample.zip

Why is this option better?

As we already noticed, Google Analytics and like services are based on JavaScript working on the page. They know nothing about static content and other files loaded from the server.

Another option (yet another extreme) is server logs. They are not always accessible, not always enabled, besides, they require writing of special parsers or analyzers. Moreover, server logs do not provide live (current moment) info. Usually log file is created daily so their analysis is only possible at the beginning of the next day.

Summing up

The method explained above is a quick and effortless way to screw downloads counter to your site using Helicon Ape mod_dbd. The example is easily expendable, e.g. you can add more fields to the table to save Referer, User-Agent, etc., or develop a customizable statistics viewer.

We’ve just given you the basement, now it’s time for you to build a house.

Best regards,
Ruslan—Helicon Tech Team

1. Cache statics

Caching static content (pictures, css files, javascript files) on the client’s side (in browser) means that having received static file once browser saves it in cache and doesn’t make a request to the server next time the html-document is requested. File will be taken from cache. Both sides win: client sends less requests, web site is working faster and server processes less requests. For instance, ordinary WordPress post page has over a dozen links to the static files (css files, pictures, scripts). Time spent on downloading these files exceeds time spent on downloading the post itself. Once having caching enabled the static content will be downloaded only once. While moving to the next page the only thing that will be downloaded is page itself. All static files will be taken from cache. In order to make browser cache static content, http-response must contain specific headers: Expires and Cache-Control. Those headers are set by mod_expires and mod_headers modules. For enabling caching, create .htacces file with the following content inside the static folder:

ExpiresActive On
Header set Cache-Control public
ExpiresByType image/.+  "access 15 days"
ExpiresByType text/css  "access 5 days"
ExpiresByType application/x-javascript "access 5 days"
ExpiresByType application/javascript "access 5 days"

In case there’s no such directory for static content and files are spread across folders of web site, than if you create following .htacces in the root of the site it will cache all static content on the web site by file extension:

<Files ~ \.(gif|png|jpg|css|js)>
ExpiresActive On
Header set Cache-Control public
ExpiresByType image/.+  "access 15 days"
ExpiresByType text/css  "access 5 days"
ExpiresByType application/x-javascript "access 5 days"
ExpiresByType application/javascript "access 5 days"
</Files>

This configuration makes server send http-responses to clients with information that pictures are to be cached for 15 days and scripts and css-files for 5 days.

2. Compress responses on the run

In order to save some time on loading the content, you can compress it. All modern browsers are able to receive comressed gzip-traffic. Text files (html-files, css-files, scripts, json-data) can be easily compressed and allow you to save 20-90% of traffic. Same time, music and video files can hardly be compressed as they have already be sized with special codecs. Here’s an example of enabling gzip-compression. Add the following line in .htaccess in the root of web site:

SetEnvIf (mime text/.*) or (mime application/x-javascript) gzip=9

As you can see, this configuration is quite simple. It’s enough to have all text documents (html, css files) and javascript-files compressed before going to the client’s side. It is worth saying, that server compresses responses only for those browsers, that support compressing. Browser informs server about its features through the headers of html-request.

3. Cache dynamic responses at server side

Often large amount of requests, addressed to database server, hinder the web site performance. For example, blog’s main page shows recent entries, recent comments, navigation menu, category list and tags. Those are several complicated requests to database. In case that information does not change often or the relevance is not vital, html-responses need to be cached without hesitation. You can choose to cache the blog’s main page once in 5-10 minutes. But that would be enough to improve main page performance in browser. Practically, application developer must decide what pages need to be cached and for how long. Also he needs to bring into life caching mechanism “out of the box” . Unfortunatelly, that doesn’t happen most of the time. Likely, mod_cache in Helicon Ape will simply and easily allow you to enable caching at server side. mod_cache supports two types of cache: disk cache and memory cache. First type saves caches data on the drive, and the second one does on memory. Memory caching is more preferable. If your server doesn’t have enough RAM, use disk cache. For example, to cache site’s homepage, we need to add the following lines in .htaccess in the root:

Header set Cache-Control public,max-age=600
SetEnvIf request_uri ^/$ cache-enable=mem

This configuration enforces caching of site’s homepage request for 10 min (600sec). Response are cached in memory. Be careful! You need to enable caching carefully. For example, pages that need authentificaton mustn’t be cached as they contain private data and need to provide different information for different users. In any cases, caching must be taking application logic into account. We’ve reviewed three simple steps for increasing the speed of your web site. Besides tangible speed-boost, which you will notice at once, the acceleration must well enhance your rating in search engine results. You can see performance graph of www.helicontech.com made using Google Webmaster tools after a simple optimization. So equip your site with these tricks and enjoy dual benefit!

Request processing contexts

In the simplest case there are only two request processing contexts:

1. server context (httpd.conf), and
2. “root folder” context (.htaccess)

Server context is executed first and after that, if further processing is allowed (no redirect or proxy happened), root folder config is processed (if present).

Picture 1. Server-wide configuration (httpd.conf)

Picture 2. Per-site configuration (.htaccess)

Picture 3. Processing order for the configs on Pictures 1 and 2

***
Now let’s make it more complicated—we’ll have the rules in the root folder and in Directory1. The processing order then becomes:

1. /.htaccess

   DirectiveA

2. /Directory1/.htaccess

   DirectiveB

Picture 4. Processing order in case of several .htaccess files

For the request to http://localhost/index.html only the first context is applied, while for http://localhost/Directory1/index.html (and other requests to deeper subfolders) the merged context 1+2 is executed. In our case it’s:

DirectiveA
DirectiveB

Thus, the child context complements and refines the parent one (but not the server one). This is true for nearly all Apache/Ape modules EXCEPT mod_rewrite. It’s one of a kind and behaves differently.

mod_rewrite behavior

Historically, or for convenience purposes, mod_rewrite contexts do not complement but COMPLETELY OVERRIDE each other. So, if we have two configs

1. /.htaccess

   RewriteRule a b

2. /Directory1/.htaccess

   RewriteRule b с

the resulting config to be applied to the request will be

RewriteRule b c

and NOT

RewriteRule a b
RewriteRule b с

which may be unobvious for newbies.

For experts! mod_rewrite has an option allowing to change this behavior and inherit the parent rules:

1. /.htaccess

   RewriteRule a b

2. /Directory1/.htaccess

   # inherit parent rules
   RewriteOptions inherit
   RewriteRule b с

makes up the following merged config:

RewriteRule b с
# parent rules are appended to the end of the merged config!
RewriteRule a b

<Directory> section

<Directory> section is equivalent in meaning to writing rules in the .htaccess located inside this directory. The only difference is that <Directory> lives in httpd.conf.
If there are both <Directory> section and .htaccess for the same directory, they are merged; if the directives inside them interfere, the .htaccess directives are preferred.

Picture 5. Processing order when there are both .htaccess and <Directory> for the same location

Let’s see how the configs are merged for the request to http://localhost/Directory1/Directory2/index.html if each directory has both <Directory> section and corresponding .htaccess file.

Picture 6. Processing order when there are several .htaccess files and several <Directory> sections which are applicable for the same request

httpd.conf

<Directory C:/inetpub/wwwroot/>
DirectiveDirectoryA
</Directory>

<Directory C:/inetpub/wwwroot/Directory1/>
DirectiveDirectoryB
</Directory>

<Directory C:/inetpub/wwwroot/Directory1/Directory2/>
DirectiveDirectoryС
</Directory>

/.htaccess

DirectiveA

/Directory1/.htaccess

DirectiveB

/Directory1/Directory2/.htaccess

DirectiveC

The following logics is applied to form the merged config:

1. First to execute is httpd.conf except for tagged sections:
   <Directory>
   <DirectoryMatch>
   <Files>
   <FilesMatch>
   <Location>
   <LocationMatch>
   <VirtualHost>
2. Distributed config is built up from the following parts:
   a. empty context is created;
   b. requested URL is divided into parts like:
   /
   /Directory1/
   /Directory1/Directory2/
   c. physical path is defined for each virtual directory:
   / —> C:/inetpub/wwwroot/
   /Directory1/ —> C:/inetpub/wwwroot/ Directory1/
   /Directory1/Directory2/—> C:/inetpub/wwwroot/ Directory1/ Directory2/
   d. corresponding section is found for each path;
   e. corresponding .htaccess is found for each path

The resulting sequence of directives will be:

DirectiveDirectoryA
DirectiveA
DirectiveDirectoryB
DirectiveB
DirectiveDirectoryC
DirectiveC

Usually directives’ order is not so important, but not in case with mod_rewrite; that’s why understanding the principles of configs merging may dramatically reduce development and debugging times.

Note! <DirectoryMatch> sections are applied not to all parts of the request (see above) but only to the deepest part, and all matches are searched for, for example, if there are two sections:

<DirectoryMatch C:/inetpub/wwwroot/Directory1/Directory*/>

and

<DirectoryMatch C:/inetpub/wwwroot/Directory1/*/>

then both of them get into the merged config.

<VirtualHost> directive

One should remember that everything written inside server context is applied to all requests and for all sites. Sometimes it may be necessary to limit the scope of directive to one or several sites and that’s the case to use <VirtualHost> section.
<VirtualHost> can reside in httpd.conf only. It is merged with server config, i.e. complements it. In case of both .htaccess and <VirtualHost> section for the specific location, the latter has higher priority and can reject server settings for the specific site (in our case localhost).

#httpd.conf
ServerDirective
<VirtualHost localhost>
VirtualHostDirectiveA
</VirtualHost>

Note! mod_rewrite offers another way to restrict scope for the rules to specific host – RewriteCond %{HTTP_HOST}.
The difference is that RewriteCond %{HTTP_HOST} must appear before each RewriteRule, while <VirtualHost localhost> groups all rules for localhost together and affects all of them. Compare:

RewriteCond %{HTTP_HOST} localhost
RewriteRule . index.php  [L]
RewriteCond %{HTTP_HOST} localhost
RewriteRule about$ about.php  [L]

and

<VirtualHost localhost>
RewriteRule . index.php  [L]
RewriteRule about$ about.php  [L]
</VirtualHost>

On the other hand, the limitation of <VirtualHost> is that it can’t be used in .htaccess.

Picture 7. Processing order when <VirtualHost> section is present in httpd.conf

Note! <VirtualHost> sections are NOT merged together – if there are several <VirtualHost>s matching the request, the one with the best match is applied. E.g.:

<VirtualHost localhost>
<VirtualHost localhost:80>
<VirtualHost *>

For request to localhost:80/page.html the second line will be executed, whereas for localhost/page.html the first one will fire.

If <Directory> section is specified inside <VirtualHost> (which is possible), the processing order is as follows: <Directory> section of the main server config is accounted first, then <Directory> inside <VirtualHost> and after all – .htaccess.

Thus, the use of <Directory> section outside <VirtualHost> will lead to application of its (<Directory>) rules to all sites (in case they use this shared folder).

Picture 8. Processing order when there are <VirtualHost> and <Directory> sections as well as .htaccess

<Files> and <FilesMatch> sections

These two behave similar to <DirectoryMatch> but are used for file names, not for the full path.
E.g., for http://localhost/Directory1/index.html#top they will find the correspondence in file system C:\inetpub\wwwroot\Directory1\index.html and will merge all <FilesMatch> sections valid for this file name (e.g. <FilesMatch *.html> and <FilesMatch index.*> will be merged).
Note! <Files> and <FilesMatch> may reside in .htaccess as well!

<Location> and <LocationMatch> sections

Are applied to the corresponding virtual path, which for http://localhost/Directory1/index.html#top is /Directory1/index.html.

Summary

Let’s now put it all together. Here’s the final sequence of sections:

1. httpd.conf <Directory>
2. httpd.conf <VirtualHost><Directory>
3. .htaccess
4. .htaccess <Files>
5. httpd.conf <DirectoryMatch>
6. httpd.conf <VirtualHost><DirectoryMatch>
7. httpd.conf <Files>
8. httpd.conf <FilesMatch>
9. httpd.conf <VirtualHost><Files>
10. httpd.conf <VirtualHost><FilesMatch>
11. httpd.conf <Location>
12. httpd.conf <LocationMatch>
13. httpd.conf <VirtualHost><Location>
14. httpd.conf <VirtualHost><LocationMatch>

***
Seems every aspect of configs processing has been covered. We understand that this article may look somewhat sophisticated, but we are sure there are enthusiasts who’ll find it helpful.

Web interface illustrates the current state of load balancers and their nodes.

The following info is shown for the balancer nodes:

• Worker URL;
• Route: name of balancer member;
• RouteRedir: name of the node to redirect requests to in case of inaccessibility;
• Factor: mamber relative weight;
• Status: state of member;
• Elected: how many times the node was chosen to process request, i.e. practically the number of processed requests;
• Transmitted: number of bytes sent to the node;
• Received: number of bytes received from the node;
• EMA ResponseTime: exponential moving average of response time
• Status TTL: period of time for which the node is excluded from the balancing process due to inaccessibility.

Here’s how you can set this handler to enjoy all this stuff:

<Location /balancer-manager/>
  SetHandler balancer-manager
  Order allow,deny
  Allow from 127.0.0.7 ::1 localhost
</Location>

Please pay attention that the URL to which the handler is mapped must be secured from unauthorized access. For instance, the access must be granted for local machine only (see example above) or basic/digest authorization must be enabled.

Feel free to try our web interface for the load balancer to facilitate control and get comprehensible statistics for any node and any balancer.

Best wishes,
Ruslan – Helicon Tech Team

Goal

Create simple cluster in which one front-end server (www.site.com), accessible via Internet, proxies some application operation in an intranet (not accessible via Internet).

To improve stability (resistance to failures) and speed the application will run on internal servers (app1.site.com & app2.site.com) which will distribute requests between themselves. In case one server is down (scheduled maintenance, upgrade, breakdown), all requests will be directed to another server.

Requests between the servers are distributed based on the response time value. I.e. the quicker back-end returns responses (better copes with the load), the more requests it will get.

The application uses sessions, so if the request contains the cookie with session id, this request must be assigned to the back-end which initiated this session. The cookie is of the following format [session_data]![backend_id].

Static content is also shared between two internal servers (static1.site.com & static2.site.com) so they need to distribute it among themselves as well.

Configuration

Here’s the sample configuration of the balancer described above:

<VirtualHost www.site.com>

# route all requests starts with /static/ to static balancer
ProxyPass /static/ balancer://static-balancer/
<Proxy balancer://static-balancer/>
  # describe static balancer members
  BalancerMember http://static1.site.com/media/
  BalancerMember http://static2.site.com/media/
</Proxy>
# enable reversing of response redirects
ProxyPassReverse /static/ http://static1.site.com/media/
ProxyPassReverse /static/ http://static2.site.com/media/

# route all other requests to application balancer
ProxyPass / balancer://app-balancer/ stickysession=sessionid routeregex=!(.*)$
<Proxy balancer://app-balancer/>
  # describe application balancer members
  BalancerMember http://app1.site.com/ route=app1
  BalancerMember http://app2.site.com/ route=app2
</Proxy>
# enable reversing of response redirects
ProxyPassReverse / http://app1.site.com/
ProxyPassReverse / http://app1.site.com/
# enable reversing of domain in Set-Cookie headers
ProxyPassReverseCookieDomain app1.site.com www.site.com
ProxyPassReverseCookieDomain app2.site.com www.site.com

</VirtualHost>

What was that?

And here’s the explanation of the code above.

<VirtualHost www.site.com> ... </VirtualHost>

section conditions that all directives inside it are applied only to the requests to www.site.com. This is especially important when the server manges several sites.

ProxyPass /static/ balancer://static-balancer/

directive tells mod_proxy that all requests beginning with /static/ must be proxied via static-balancer balancer.

<Proxy balancer://static-balancer/> ... </Proxy>

section stores directives for static-balancer, members of this balancer in particular.

BalancerMember http://static1.site.com/media/

directives define balancer members: their working URL and load factor.

ProxyPassReverse /static/ http://static1.site.com/media/

directives are needed to reverse proxy the redirects coming from the back-ends. All redirects with URLs like http://static1.site.com/media/[path] will be substituted with http://www.site.com/static/[path].

These were the rules for static content balancer. Now let’s look at the balancer for the application itself.

ProxyPass / balancer://app-balancer/ stickysession=sessionid routeregex=^(.*)$

directive tells mod_proxy that all other requests must be proxied through app-balancer balancer. As the rule for /static/ folder is above, it will be applied earlier.

The balancing must be relative to back-end response time (default lbmethod=byresponsetime), i.e. the back-end with faster response time will get more requests with probability reverse-proportional to the response time. Response time for each back-end is averaged according to exponential moving average algorythm.

stickysession=sessionid parameter defines the name of the cookie storing the session id, and routeregex=!(.*)$ defines the regular expression to match the request route in the cookie value. In our case it’s everything after the exclamation mark (‘!’).

BalancerMember http://app1.site.com/ route=app1

directives define app-balancer members. route=app1 assignes the name to this node (route) which will be used to direct requests with corresponding sticky session.

ProxyPassReverse and ProxyPassReverseCookieDomain directives serve to reverse proxy redirects (Location header) and domains in cookies (Set-Cookie header).

Other types of load balancers

The method of load balancing is defined by lbmethod parameter of ProxyPass directive and may be one of the following:

• byrequests to perform weighted request counting;
• bytraffic to perform weighted traffic byte count balancing;
• random to perform weighted random balancing;
• byresponsetime to perform weighted response time balancing.

Nodes accessibility

The node is considered inaccessible if the balancer cannot connect to it. In such case the balancer marks it as IN_ERROR and excludes from the balancing process. In our situation it means that if app1.site.com is not accessible (e.g. due to upgrade), then the balancer will route all requests to app2.site.com. statusttl parameter of BalancerMember directive defines the period of time in seconds after which it’ll retry to establish connection to this node. The default is 300 secs.

You can learn more about mod_proxy directives and features from mod_proxy manual.

Best wishes,
Helicon Tech Team