As you may have heard the web has come into the 2.0 stage. There are many opinions and differences of opinion as to what and how the web has changed. Discussions on the subject mostly surround use of technology and habits that have been around for a long time. Javascript and AJAX seem to rise to the top of any pile of topics. But the topic of how the new Web 2.0 technology influences the server-side of things never seems to come up much.

Supporting AJAX on the Server and Client

In recent past when Microsoft released IIS 7 for Vista and the IE7 web browser they spoke of supporting the the AJAX technology. More on Microsoft Windows iis7 later. But the questions of what is really necessary to support AJAX was never asked or answered. So what is the secret sauce needed to make the new Web 2.0 technologies work more efficiently? We can find and see many potential client-side browser solutions that answer this question but what about the web server that has to deliver responses? How does the HTTPd software hold up against the pressures of Web 2.0?

A webserver needs to have a few things that make running AJAX a plus for large web sites seeking to enhance the user experience and speed up interaction.

Time to Live

The tcpip stack is very important,concurrent connections, the number of database connections and how they are handled will directly effect the way an AJAX appliction performs. Since AJAX ultimately has to connect to a server-side script what happens at the server is equally important as what happens on the users client. Remember the user is not getting a page reload and so they can potentially send more requests and create more connection traffic than usual. A page reload gives the server a split second breather whereas AJAX might smother it. An auto-completion application connected to a resource intensive SQL query might kill a web server by allowing a high number of requests per second and starting many more new connections at the same time. Potentially this could be exploited to create a new type of DDos attack.

FastCGI

CGI programming is slowy making a come back with those that are new to web programming. Although PHP does have the top spot for web programming popularity it is not the perfect programming solution for applications using AJAX as a front end. There are areas where CGI in languages like Java,Ruby, C and Python are more robust and powerful. But normal CGI suffers from two major drawbacks that AJAX usage can possibly make worse. The following is an excerpt from Wikipedia on CGI and Fastcgi...

CGI is a protocol for interfacing external applications to web servers. CGI applications run in a separate process, which is created at the start of each request and torn down at the end. This "one process per request" model makes CGI programs very simple to implement, but limits efficiency and scalability. At high loads, the operating system process creation and destruction overhead becomes significant and limits scalability. In addition, the CGI process model limits resource reuse techniques (such as reusing database connections, in-memory caching, etc.).

Instead of creating a new process for every request, FastCGI can use a single persistent process which handles many requests over its lifetime. Processing of multiple requests simultaneously is achieved either by using a single connection with internal multiplexing (ie. multiple requests over a single connection) and/or by using multiple connections. Many such processes can exist, something that can increase stability and scalability. FastCGI also allows programs to get the web server to do certain simple operations, like reading in a file, before the request is handed over. Environment information and page requests are sent from the web server to the process over a TCP connection (for remote processes) or Unix domain sockets (for local processes). Responses are returned from the process to the web server over the same connection. The connection may be closed at the end of a response, but the web server and the process are left standing.

After reading the above it should be apparent how CGI by itself works against any gains made by using AJAX and how Fastcgi works hand in hand making things more effective and less server resource intensive. It also give a hint to why Ruby on Rails uses Fastcgi and AJAX.

The web server should be light and fast and able to present the visitor a in a blink without being dependant on tons of hardware to do so. While Apache is fast it is not light. Apache is bloated with many things that mordern website frontends do not need. This causes high CPU usage. AJAX has the potential increases CPU usage even when the information being returned comes from a cache. To compensate web server software should have a small foot print and not significantly increase CPU usage by performing used or unusable operations in the background.

Apache is old and bloated

Apache is the defacto web server on the web today but as mentioned earlier it is not a Web 2.0 friendly environment. Being larger than necessary and not fully supporting technologies like Fastcgi make it an inefficient tool. There are alternatives to Apache that have long established histories and are better suited to deal with the needs of Web 2.0 technoly. Unfortunately most of these are commercial products which make them poor contenders for winning a place along side Apache. There is one however that stands out , is free and seems to be gaining a signifcant portion of the web, Lighttpd (called Lighty in most circles).

Enter Lighty

Lighttpd is a project that is gaining momentum. Though Lighttpd does not implement the entire Fastcgi protocol it does enought to make it a viable alternative to Apache. The majority of medium to small websites can use Lighttpd and it can be used in certain situations at the enterprise level as well. One of the most interesting things about Lighttpd use is that it is being used mostly to take the load off of Apache for certain types of content delivery.

One of the largest reasons that Apache is so popular is because finding information and help from within the community is very easy. Most of the non-commercial competion for Apache do not have a large and open community that can provide support. Lighttpd differs in that there is a blog, forum and a following that is growing daily. There also seems to be a constant development effort to fix bugs and shortcomings within the software. This instills confidence and trust in the user base.

Lighty on VPS is a perfect match

A new trend in hosting is the use of VPS dedicated servers. These servers while versitle and powerful are held back by the fact that memory intensive applictions like Apache eat up most of the resources. Increasing the memory means having to pay more of course and so VPS popularity is slow in reaching the web masses. Lighttpd and others like it provide a way for VPS to be used efficiently and at a lower cost.

The performance benefits of lighttpd, particularly for static or PHP-based pages can be seen on many production web sites that have high-traffic. Isohunt.com and mininova.org which have been said to serve more than 1,000 page requests per second run Lighttpd. Major web sites like YouTube, Wikipedia and Meebo are using Lighttpd in conjuction with Apache to speed things up. YouTube, for example, delivers static content like Flash videos via lighttpd while still using Apache to handle dynamic pages. This hybrid architecture of pairing lighttpd with a full-featured but more resource-hungry server is becoming an increasingly popular way to scale resources. No hosting companies are offering a cheap and Lighttpd package as of yet. But it will not be long before they do with major contenders for web traffic putting Lighttpd through some real life benchmarks.

But it is not just the fact that Lighttpd is being used by some larger websites that make it a good choice for Web 2.0. There are other factors like being GPL, being made Windows ready (with config tools like light tray) and having a growing number of shared web hosts using it that will make Lightttpd one of the most important parts of the Web 2.0 culture.

Happy Publishing!

This article brought to you by the Hiveminds Magazine - Staff. Contact us if you want to post an article or announcement anonymously