• Installing work environment
• Writing a simple app
• Deploying the app on the server

As a resume you’ll see the results of the tests contrasting performance of Ruby-apps run (in different modes) on Windows and Ubuntu.

Setting-up environment

First, we need to download and install Web Platform Installer, run it, click Options and add the link to Helicon Zoo Feed: http://www.helicontech.com/zoo/feed/ into the «Display additional scenarios» field.

In result, WebPI will add Zoo tab with «Applications», «Packages», «Modules» and «Engines» sections.

Installing Ruby on Rails

In Engines section you can choose engines to be installed including Ruby on Rails 3.1 and 2.3. Ruby version 1.8 and 1.9 are also available. By default Rails 3.x installs Ruby 1.9 as a dependency, while Rails 2 will install Ruby 1.8.

For convenience the Packages section offers Ruby Hosting Package which includes the following components:

• Ruby 1.8.7 andRuby 1.9.3;
• Rails 2.3.11, 3.0.10 and 3.1;
• Ruby DevKit (for assembling C-extensions);
• Popular gems: mysql2, pg, sqlite3, mongo_mapper, tiny_tds, activerecord-sqlserver-adapter, devise, authlogic, jekyll, formtastic, will_paginate, Sinatra, ramaze, camping-omnibus, Thin, Goliath.

Creating your first web-site

A convenient way to create new web-app is using WebMatrix and IIS Express. On Zoo tab, under Packages section in WebPI you can find WebMatrix Templates package, offering different templates including the one for Ruby on Rails.

If you don’t yet have WebMatrix, it will be automatically installed with the WebMatrix Templates package. Keep in mind that downloading and installing all packages may take some time. Having templates installed run WebMatrix and on the main page select Site from template and then Rails Site.

After you created the Rails Site, follow the given URL or press Run to see the page with instructions.

The template is designed for development of Rails 2.3, 3.0 or 3.1 applications. At the moment there’s no application under the site folder, only configuration files. Let’s create it using the command:

rails new .

If you don’t explicitly specify the Rails version to use, it will use the latest available one. As in our case we installed Ruby Hosting Package, which includes three Rails versions and the latest of them is 3.1, the app template will be created based on Rails 3.1.

If we now refresh the page, we’ll see standard Ruby on Rails welcome page:

Development environment

For code editing you’ll need an editor or dev environment. If you prefer IDE with debugger and refactoring tools, consider one of the following options:

• Aptana (free, http://aptana.org)
• NetBeans (free, http://netbeans.org)
• RubyMine (commercial, http://www.jetbrains.com/ruby/)

Each of these offers a bunch of development and testing tools for Ruby apps and supports version control.

For those who will make do with simpler solutions there are:

• KomodoEdit (free, http://www.activestate.com/komodo-edit)
• Redcar (free, http://redcareditor.com/)
• SciTE (free, http://www.scintilla.org/SciTE.html)
• E TextEditor (commercial, http://e-texteditor.com/)

For our app we used Aptana:

MVC

Ruby on Rails is based on the MVC architecture (model, view, controller). This approach has several advantages:

• Isolation of business logic from interface;
• Less code repetition (DRY principle — don’t repeat yourself);
• Relatively simple development hanks to strict code distribution based on purpose (e.g. the code for HTML form output is not mixed with the code for DB processing).

Model defines the database structure in terms of object-oriented programming. In Rails model is an ordinary class inheriting all necessary functions from ActiveRecord::Base class. Instance (object) of this class defines one line from the corresponding database. Thus, models conceal the peculiarities of interaction with particular DBMS from developer.

View is the interface shown to users. On this stage developer creates templates which are transformed into HTML, CSS orJavaScript code.

Controller connects model with view. It’s usually controller that contains the main logic. Essentially, controllers are Ruby classes. Each public method of controller is called action. If you have controller named “Home” and it contains the method named “index”, then running /home/index in browser will evoke “index” action.

When a request comes to the application, the routing mechanism (in config/routes.rb file) decides which controller cares about that type of requests. Aside from the URL a set of other conditions may be taken into consideration, e.g. you can assign different controllers for different browsers, for mobile clients etc.

So, having chosen the controller, it defines what action will process the request. At this point one can also apply numerous conditions. The action itself performs some calculations and DB-related operations. When the action is finished the view comes on the scene. The data from DB or some result are transmitted to the templates. Then the HTML page is generated from the templates (there are templates from CSS and JavaScript as well) and the response page in sent to the user.

Writing the application

The classic example of Rails app is the simplest blog. We won’t ignore this tradition. So, let’s delete the welcome file public/index.html and create controller “Home” with action “index” – this is going to be the blog main page. This is done with the following line run from app folder:

rails g controller home index

If we now request /home/index, we’ll get the page from the template created for “index” action.

Afterwards, we’ll create a simple Post model which will define each blog entry in the DB. In Ruby code the model is a class and it is represented in DB as a table. Thus, the object of Post class is a line in the corresponding table in database.

To create model you can simply run “rails g model Post…” but let’s make use of a very handy tool – scaffolding. The “rails g scaffold” command creates not only the model class itself and tests for it, but also actions drafts and views templates for adding, editing and removing model objects. If we execute this

rails g scaffold Post name:string title:string content:text

we’ll get “Post”model in app\models\post.rb, “Posts” controller in app\controllers\posts_controller.rb with actions index, show, new, edit, update, create and destroy, plus a DB migration scenario in db\migrate. The command will also have created the headers for tests and HTML templates. Notice that we haven’t yet written a single line of code!

Next, we’ll run the command to create the database (if it’s not yet created) and the table “posts” with the fields “name”, “title” and“context”:

rake db:migrate

The command for database migration is applied for creating and editing database structure in accordance with our object model. It should be executed every time you make changes to the application model. All the magic of matching the DB structure with our model is done automatically and all the data stored in the database are retained.

FYI, in this example we use SQLite which is default for Rails. However Rails can work with many other DBMS hiding details of their cooperation from the user.

Actions of “Post” controller are accessible at /posts/ address.

If you press “New post”, you’ll see the form:

After filling all fields we get to the new post page:

Note that there was still no code written. Now let’s do some editing. For instance, we may need to make post name and post title obligatory fields so that corresponding cells in the DB are always non-empty. Luckily, Rails provides very simple validation mechanism. We should just fix the model file as follows:

class Post < ActiveRecord::Base
      validates :name,  :presence => true
      validates :title, :presence => true,
                :length => { :minimum => 5 }
end

In there we specify that “name”and“title” fields are obligatory and “title” should contain not less than 5 characters. No need to apply migration after this change as validators are not directly related to database; the check is performed on the level of Ruby code.

If you now leave the “name” field empty, you’ll get an error:

Let’s make it a little more complicated and add the comments feature. We’ll create a “Comment” model with the following command:

rails g model Comment commenter:string body:text post:references

Pay attention to “post:references” parameter. It connects «comments» table with “posts” table.

Now refresh the database:

rake db:migrate

next, we’ll set up the relation “has many” for Post model:

class Post < ActiveRecord::Base
      validates :name,  :presence => true
      validates :title, :presence => true,
                :length => { :minimum => 5 }

      has_many :comments, :dependent => :destroy
end

The code is intuitively clear. Each Post object may have a number of comments. “:dependent => :destroy” tells that when post is deleted all comments are deleted as well. As we didn’t use scaffolding this time to create a model for comments, we now need to generate corresponding controller:

rails g controller Comments

In config\routes.rb file replace “resources :posts do” with:

resources :posts do
   resources :comments
end

In this way we specify how the “comments” controller will be available. In our case it’s put into “posts”, so the links will look like http://localhost:41639/posts/1/comments/3.

Then we need to refresh the template app\views\posts\show.html.erb so that it will become possible to add comments. After:

<p>
  <b>Content:</b>
  <%= @post.content %>
</p>

add the following code:

<h2>Comments</h2>
<% @post.comments.each do |comment| %>
  <p>
    <b>Commenter:</b>
    <%= comment.commenter %>
  </p>
  <p>
    <b>Comment:</b>
    <%= comment.body %>
  </p>
  <p>
    <%= link_to 'Destroy Comment', [comment.post, comment],
                :confirm => 'Are you sure?',
                :method => :delete %>
  </p>

<% end %>

<h2>Add a comment:</h2>
<%= form_for([@post, @post.comments.build]) do |f| %>
  <div class="field">
    <%= f.label :commenter %><br />
    <%= f.text_field :commenter %>
  </div>
  <div class="field">
    <%= f.label :body %><br />
    <%= f.text_area :body %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>

Finally, we’ll define the logic of controller operation in app\controllers\comments_controller.rb

class CommentsController < ApplicationController
  def create
    @post = Post.find(params[:post_id])
    @comment = @post.comments.create(params[:comment])
    redirect_to post_path(@post)
  end

  def destroy
    @post = Post.find(params[:post_id])
    @comment = @post.comments.find(params[:id])
    @comment.destroy
    redirect_to post_path(@post)
  end
end

And everything is ready for adding comments to the post:

The basic functionality is implemented. As the last step we’ll protect some of the actions, so that unwanted people don’t have access to them. The more comprehensive way is to use registration, sessions, cookies etc., but to stay simple we’ll take Basic authentication, the more so because in Rails we need only one line to enable it. Put the following in posts_controller.rb:

 http_basic_authenticate_with :name => "admin", :password => "123",
                              :except => [:index, :show]

We have hard coded the login and password. “:except”parameter excludes “:index” and “:show” actions as they don’t need authentication.

Deploying on server

So, we’ve created the application and now, logically, want publish it to Internet. For that purpose we’ll set up Windows server to work with Rails in production. We’ll have to repeat several steps from the beginning of the article which were used to install developmet environment:

1. install Microsoft Web Platform Installer;
2. add Helicon Zoo feed;
3. install Ruby Hosting Package from Zoo repository.

Before installation make sure WebPI is set up to install applications for IIS and not for IIS Express. After these three steps are completed the server is ready to host our application. For the moment the following server platforms are supported: Windows Server 2008 and 2008 R2, 32-and 64-bit versions.

So, first, we create an empty web-site via IIS manager or your hosting panel. Then upload your application to the server via FTP or WebDeploy. In case with WebDeploy the folders will be also given proper permissions automatically, if needed. You can also use Git or any other version control system and deployment system, but that falls beyond the scope of this article.

The application will be executed on Windows Server under IIS with the help of Helicon Zoo Module. This module was initially designed as a hosting solution, so all applications are isolated and do not interfere. The module with its default options works in automatic mode, creating one worker process by default, when the load is low and increasing the number of workers up to the number of CPU cores of the server providing maximal performance under heavy loads.

Helicon Zoo applies the concept of engines and applications. The engines section define what to run and how, on which protocol and port, what maximal number of workers are allowed and other global settings which are defined in applicationHost.config. Then, under the site you can create an application using specific engine and send all parameters necessary for this app’s operation to it. This concept allows for separation of hosting administrator duties from the clients’ burden (and client from client as well). You can learn more about Helicon Zoo Module and its settings here: http://www.helicontech.com/zoo/module.htm

Please pay attention to deploy.rb file in the root of the site and DEPLOY_FILE and DEPLOY_LOG parameters in web.config. Zoo executes deploy.rb upon each start of IIS application pool. This approach may appear especially helpful for those who don’t have administrator privileges on the server. As for deployment you’ll probably need to do “bundle install”or apply database migration, you can simply restart your application on the server and deploy.rb will be executed automatically. There is pre-defined deploy.rb file in the Ruby on Rails application template with most popular commands.

It’s worth mentioning that deploy.rb script is executed by the same Windows user that runs IIS application pool. As a rule this user has rather limited permissions that should be accounted for when you write your commands. As an example, ordinary “bundle install” command may lead to error because the user is not allowed to write directly into Ruby installation folder. Way out: save all gems under the site in a special folder “vendor/gems” by executing “bundle package” command in the application folder before sending it to the server. And in deploy.rb put the command “bundle install –local –path vendor/gems”.

The errors occurring for deploy-script may be logged in the file specified in DEPLOY_LOG environment variable.

The last issue to point out during deployment is RACK_ENV variable in web.config. In web.config created from WebMatrix template the RACK_ENV variable contains the value “development”. This enables Rails in the mode more suitable for development. When you put the application on the server, change the value to “production”. BTW, “production” is actually default.

Performance tests

Machine used as a server contained Core 2 Quad 2.4 Ghz, 8 Gb RAM, 1Gb LAN. For load generation we took more powerful PC and Apache Benchmark tool with a command “ab.exe -n 100000 -c 100 –k”. For Apache and Nginx servers we used Ubuntu 11.04 Server x64. IIS 7 tests were run on Windows Server 2008 R2. No virtual machined where used – bare hardware.

We’ve conducted three test scenarios:

1. Rails had to output the current time in high resolution. The time was chosen to ensure the response doesn’t come from cache;
2. Rails read from MySQL database and;
3. Rails performed writing into MySQL  database.

We performed tests with Ruby 1.9.3, Rails 3.1.1 and MySQL 5.1.54. in case of HTTP transport, Thin acted as a backend HTTP service. Neither Unicorn nor Passenger work for Windows. So, there were three configurations for testing: Windows + IIS 7.5 + Helicon Zoo + Thin, Ubuntu + Apache + Passanger, Ubuntu + Nginx + Thin.

Below are tests results (in requests per second):

Here are more detailed ab graphs for the first test (time output):

Resume

Ruby on Rails proved itself a perfect framework for quick and easy web development. Of course, Ruby is not the one and only. In the next articles we’ll shed some light on Goliath and Sinatra.

We would also like to underline that Windows is a mighty platform for both development with Ruby and running Ruby-apps in production. And if earlier the difference in Ruby performance on Linux and Windows was dramatic, now the performance, as well as convenience of Ruby on Rails for Windows has significantly improved to a degree that performance is no more a key criteria for choosing the platform.

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