First of all the use of some software is needed not because of itself, but because of the need of some specific functionality. In my case this was the need of real time news feed. Of course there is a way to make this without Node.js, as I’ll describe later in this post, but there are several disadvantages. However to begin from somewhere, let me explain what is Node.js.

Introducing Node.js

Perhaps the best way do describe what is Node.js is from its about page.

Node’s goal is to provide an easy way to build scalable network programs. In the “hello world” web server example above, many client connections can be handled concurrently. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation.

…

In general Node is a program using the Google Chrome’s V8 JavaScript engine, which in turn is a program that can parse and execute code written in JavaScript. V8 is a very very interesting project itself. First of all from Google have developed this engine especially for one of his products – their browser Chrome. It pretends to be and by no means is one of the masterpieces of Google. It is fast and reliable engine, written in C++ and JavaScript, as Wikipedia’s page says. Actually this code is open source and can be embedded in whatever application written in C++. Thus you can have in your application a JavaScript engine.

Such kind of application/server is Node.js. With V8 embedded into, Node is intended to run on a machine and to serve some requests. Just like a normal web server, but with few differences. First of all Node is not only serving HTTP requests, but also TCP. Well I’m not so deep into this yet, but so far that works for me. What I need for now is its web serving functionality.

The way Node works, however is different from what we know from every other web server. Here it is a normal server in general:

Whenever a request comes to the server, it tries to return the response as fast as possible. This is one of the main goals of every web developer team – to make the application as fast as possible. However in Node the things work different:

Here the server doesn’t return immediately the response, but holds as long as possible until some “event” occurs. You can thing of Node as a classical chat server. Until one of the peers doesn’t write a message, the other doesn’t receive anything.

Some may be confused as how you can use both the typical web server, as Apache, with Node as another web server within the same page. The answer is – with AJAX. As you know thus you can have only one chunk of your page talking with the server – in this case the entire page is returned by Apache, but inside the page you can have a chat app using Node as a server, working perhaps on a different port on the same machine.

Typically this scenario can be simulated without Node, but as I said, with some disadvantages. Let’s say you have two browsers and one server – you can infinitely loop AJAX calls to the server and whenever there is new message on the server return it to the browser – this is quite inefficient. There are two approaches in this case.

1. You can make those AJAX calls too recently and you can have a call every N seconds. In that case if N is to short you’ll have too many calls and in case the other peer doesn’t make anything the server will be unusually loaded with no practical effect.
2. In the second case you can choose to make N too long – for instance 20 seconds. This is also bad, because during this period of time the peers may want to interact and chat.

In that case Node is a web server, but simply doesn’t return the response until a specific event doesn’t occur. How does this look like in a web browser. You may know how looking into the Firebug console for every AJAX call you see the request and how many seconds it has taken. If you make an AJAX call to a Node server app the request just doesn’t respond immediately.

Installing Node.js

The process of installation is described quite well, so I’m going to describe it in few steps.

1. Download the application from Git, note that V8 is embedded inside. The version while this post was written and of course was stable is v0.2.4
2. For those familiar with Unix/Linux systems, there are three simple steps following, however without GCC (Gnu Compiler Collection) you wont be able to proceed! I’m writing this especially for the Mac OS users, as they may know there is no built-in GCC there.
3. ./configure
4. make
5. make install
6. make test (optional)

This in general is enough. After all that you can write the node command in your terminal. However if there are some problems while compiling it you may refer to Git and the Node community for more help. Don’t forget that V8 can work only on x86, x64 and ARM architectures.

Summary

There are few things that can be summarized now:

1. First of all Node can be a web server, as Apache is, but with the option to respond on event firing.
2. You can request it either with a web page loaded in your browser or within a chunk of the page via AJAX.
3. To install Node you need GCC. It comes with V8 JavaScript engine inside, which can run only on x86, x64 and ARM.

So far so good! Now we have Node installed, practically useless, because there is no application running on it. In my next post I’ll describe how to run your first application.

First of all there are several things to know about Zend Framework and caching. Whenever you work on a big web application caching is one of the mostly used mechanisms of speeding up the app and improve user performance. In general the task and the solution are pretty simple and natural.

As the application grows up the visitors become more and more impatient about what they receive. A single page is becoming slower and slower and the result is painful. First of all every time a user hits a page the application server uses the web server, a script interpreter, a database server and potentially the file system. But that’s not all. After all this output is generated on the server, as HTML in the most cases, it is sent to the client where again CSS and JavaScript engines parse and execute them.

In this scenario it’s easy to imagine how many time is spent. While there are several techniques to optimize the client side by optimizing JavaScript, CSS and the static images used for the design of the site, here I’m going to talk more about the backend.

Beside the Optimization

Let’s assume we’ve one of the very used combination between Apache (as a webserver), PHP (as server scripting language) and MySQL (as database server). Here you can choose to optimize all three of them. However beside the optimization of them one of the most simple steps you can do is to cache the output generated by these three branches of your web app.

Caching the Content

In fact you can cache only single parts of the whole process. For instance you can cache only the result returned by some slow database query. Let’s imagine a query takes about 2 seconds to execute. Now you can cache the result into a file and during the cache is active, i.e. it has not expired, the application takes it from a file stored somewhere in the file system.

In a typical Zend Framework scenario you can first setup the frontend and backend options of the cache.

$frontendOptions = array(
	'lifetime'                => 600, // in seconds - this is 10 seconds
	'automatic_serialization' => true,
);
$backendOptions = array('cache_dir' => 'cache/');
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
		
$cacheKey = md5('mykey');

if (!$cache->load($cacheKey)) {
	$slowQueryResult = $article->fetchAll();
	$cache->save($slowQueryResult, $cacheKey);
} else {
	$slowQueryResult = $cache->load($cacheKey);
}

You can setup different options here by setting up the cache directory, lifetime, etc.

Note that the cache directory must exists and with write permissions and Zend Framework doesn’t create it for you and will throw error.

The problem here is that now you cache only part of the generated content and in many cases this is still too slow for most of the users. However all the work (in most of the cases) of the web server, the script interpreter and the database server result in a simple HTML output. What if you have this output generated or cached for you and when the user hit the page the server will return this pre-generated code?

This is indeed very fast, because it’s similar to return a text file, as the HTML is simply formatted text.

Caching the Entire Page

Before I proceed, I’d like to say that I work with Zend Framework 1.9.x. Now in the latest versions of ZF there are new mechanisms of caching the output even Zend_Cache_Frontend_Page works fine on them.

You can simply setup the page cache within few simple lines of code:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
	'cache' => true,
         'cache_with_cookie_variables' => true,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

However my advise is to place this code as high as possible, because this will cache everything generated as output. It’s a good practice if you place this even in the bootstrap before you make the connection with the database. Actually you don’t need a database connection when you’ve to return a simple text(html) file.

This will improve your app’s performance a lot!

However there are few things to know. When you setup the cache to work even with cookie variables, you can see that hitting the page with different browsers Zend Framework will generated different cache pages. This is quite useless because than you don’t have any benefit of caching the content.

First of all let me say that THIS IS NOT A BUG! of ZF. Simply the framework will use the cookie variables to generate the cache key. It’s obvious that different browsers, even more different users, will have different cookie set and the framework will generate different cache keys for them.

Thus you’ve to change the setting to generate the cache key from cookie variable by explicitly set this option to false:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
		 'cache' => true,
         'cache_with_cookie_variables' => true,
         'make_id_with_cookie_variables' => false,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

Note that in this example we cache every single page generated by the framework explained in the regexps. This is not so good especially when the users have the possibility to login and to see customized content for them, so you can be careful what you cache.

A typical problem that this solution solves is when your application uses Google Analytics. As you may know Google Analytics sets up a cookie every time when an user hits the page, so every time the framework will generate a different cache for him and in result he won’t see any benefit and performance improvement from your site.