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!
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!
