Sunday 22 September 2013

The First step to Change is Understanding

To enhance anything, we first need to completely understand it. Inside out.
Only then can we make sure that the enhancements augment the preexisting model perfectly.

Our first encounter with boa was in the classroom, although a brief one, it implored us to explore..

To bring about a change, we also need to know why it is imperative to do so and hence understand the shortcomings of the current paradigm.
Having already learnt about the different approaches to building a scalable web server, we concluded that boa, being implemented using the select approach, did have some limitations inherent to the model itself.

The select( ) system call, is not entirely scalable, which is as a consequence of the limit imposed on the number of clients - indirectly by the size of the fd_set, which generally is 1024.
It takes a state based approach that makes the kernel maintain the entire set of file descriptors.
To determine the file descriptor of interest (file descriptor on which data has been received / the one to which data has to be written to), this set has to be scanned in its entirety. This is time consuming and inefficient as the result sets are mostly sparse.

The epoll( ) system call in Linux and kqueue( ) in BSD can be used for overcoming the aforementioned overhead.
The epoll mechanism essentially lies in between that of an event based approach and a state based one. It does not set any limit on the maximum number of connections. It is also considered better in terms of performance as compared to the select based approach.
The major performance enhancement comes from the fact that the epoll system call relies on the arrival of events on particular file descriptors and does not scan the entire set of fds linearly. It also supports two different modes of operations: edge triggered and level triggered.
The kqueue approach, though is very similar to that of epoll, provides a further increase in performance. It allows multiple updates of the specified set in a single system call.

Having looked at into why something has to be changed, we decided to look into what exactly had to be changed and most importantly, things that have to be left unchanged because - Change for the sake of change is not always a good idea!

3 comments:

  1. Assuming 100+ clients are being served by web server and assume that select generally returns 100+ fds (i.e. all clients are communicating heavily). Does the scalability issue still favours epoll?

    ReplyDelete
    Replies
    1. Theoretically, select would work better in such a scenario.
      But such a situation being rare, epoll offers higher performance since the probability of all the clients interacting heavily is low.

      Delete
    2. We intend on a follow-up post that compares performance measures of select and epoll.

      Delete