Elli is similar to Mochiweb, in that there is a pool of processes all accepting on the socket (doesn't work on Windows, I'm told). When an "acceptor" gets a connection, it handles that client for the lifetime of the connection, which might mean multiple requests if keep alive is used. Unlike Cowboy, Misultin and Yaws, no process is spawned after accepting and no process is spawned to run the user callback. This makes for better performance and it is more robust, as the processes cannot get out of sync. I could not make any of the existing projects work this way without completely rewriting the core.
The biggest difference between Elli and the other Erlang webservers however is the programming model. Mochiweb, Yaws, Misultin and Cowboy give you helper functions for writing a response on the socket. This makes it easy to send the body before you send the headers, send multiple bodies, etc. In fact, it makes it so easy that Cowboy tries really hard to help you avoid this with the cost of higher complexity in the user code (need to pass the return value from every helper function into the next calls).
The programming model offered in Elli is similar to the "rack" model of request-response. You get a request and return a response which is serialized by Elli into the actual HTTP response. This makes it very very easy to reason about and test the controller logic by creating a fake request with your paths, body, etc, then checking the response, no sockets or processes involved. This model breaks when you want to do streamed and chunked responses, which is handled differently. At Wooga, we use the chunked responses to send real-time notifications.
Another big upside of the request-response model is that you can write pluggable middlewares to extend and customize Elli. For example, you can add access logging, real-time stats dashboard (https://github.com/knutin/elli_stats), basic auth, compression, basic media serving and when I get around to it, even the "Date" header. If you don't want these features, you can simply turn them off. This might sound complex, but in practice it is very powerful. We are running out of CPU and being able to turn off features completely is a big win. You also don't need to deal with unused features causing problems on the critical path.
Starting from scratch allowed me to make some tough choices in the name of robustness and performance, at the cost of sacrificing features considered essential in a more complete server.
Author of Elli here.
Elli is similar to Mochiweb, in that there is a pool of processes all accepting on the socket (doesn't work on Windows, I'm told). When an "acceptor" gets a connection, it handles that client for the lifetime of the connection, which might mean multiple requests if keep alive is used. Unlike Cowboy, Misultin and Yaws, no process is spawned after accepting and no process is spawned to run the user callback. This makes for better performance and it is more robust, as the processes cannot get out of sync. I could not make any of the existing projects work this way without completely rewriting the core.
The biggest difference between Elli and the other Erlang webservers however is the programming model. Mochiweb, Yaws, Misultin and Cowboy give you helper functions for writing a response on the socket. This makes it easy to send the body before you send the headers, send multiple bodies, etc. In fact, it makes it so easy that Cowboy tries really hard to help you avoid this with the cost of higher complexity in the user code (need to pass the return value from every helper function into the next calls).
The programming model offered in Elli is similar to the "rack" model of request-response. You get a request and return a response which is serialized by Elli into the actual HTTP response. This makes it very very easy to reason about and test the controller logic by creating a fake request with your paths, body, etc, then checking the response, no sockets or processes involved. This model breaks when you want to do streamed and chunked responses, which is handled differently. At Wooga, we use the chunked responses to send real-time notifications.
Another big upside of the request-response model is that you can write pluggable middlewares to extend and customize Elli. For example, you can add access logging, real-time stats dashboard (https://github.com/knutin/elli_stats), basic auth, compression, basic media serving and when I get around to it, even the "Date" header. If you don't want these features, you can simply turn them off. This might sound complex, but in practice it is very powerful. We are running out of CPU and being able to turn off features completely is a big win. You also don't need to deal with unused features causing problems on the critical path.
Starting from scratch allowed me to make some tough choices in the name of robustness and performance, at the cost of sacrificing features considered essential in a more complete server.
Knut