Using Erlang for your Web 2.0 Application Server

In the last post, I gave an overview of the evolution we went through. Today I want to describe in more detail what we have built. There is a lot of ground to cover, so I will focus for now on the front-end of the server architecture, i.e., the part that interacts with the clients: the browser and the PowerPoint add-in.

We will discuss our approaches to database clustering (using pg2 and mnesia), full text search (using mnesia) and file storage (using Amazon S3) in future articles.

A simple URL mapping layer

We built a simple layer over Yaws to map URLs of the form x/y to calls to module www_x, function do_y and prepare the returned value (JSON, XML, HTML or simply an error code) for the response.
The AJAX calls and the XMLHttpRequests from Flash use JSON. The calls from the PowerPoint add-in expect XML. HTML is only generated for the requests that render the initial screens (login page, main page, etc).
The module www_x must also implement a check_access function that our layer calls first before calling do_y. Most of the time check_access calls a utility function that checks your cookies, in some cases no authentication is required (e.g. the login screen).

No sessions

The server keeps no state about sessions. Each request is self-contained which allows us to use any load balancing solution or to bring servers down for short amount of time without logging out users. Instead we rely on cookies (which we pass around as a request parameter, in the case of the PowerPoint add-in calls). Simply storing user (and other) ids in the cookie would be unsafe. Storing a key that would need to be looked up to recognize a user would effectively mean having persisted session ids. So instead, we store the user (and other) ids in the cookie in an encrypted string.

Apache + Yaws combo

On the deployment side, we started with Yaws serving static and dynamic content.
We then went through a benchmarking exercise (using Ab and Tsung).  We could fill an article just on that, let just say that at the end, Apache 2 with the right configuration and the worker MPM did better on our tests than Yaws 1.68.
After that, we had Apache for static requests, and Yaws behind Apache (using mod_proxy) for dynamic requests. More benchmarking showed us that Yaws alone was much better than Apache + mod_proxy + Yaws for dynamic requests.
So now, we have Apache 2 for static requests and Yaws for dynamic requests. personal.slideaware.com goes to Yaws while static.slideaware.com goes to Apache.

Coming next…

SlideAware  Personal helps user distribute presentations:

• either asynchronously with controls about who can see the presentation and analytics about what was seen and who saw it,
• or synchronously (think WebEx).

Our next technology post will describe how we can support many live slide shows simultaneously thanks to Erlang.