Excellent reference. State Threads looks very attractive.

It's an "event based" server written in C, meaning that it uses select or poll or some other 'event based' mechanism to do its work.

Erlang might be an interesting choice for your network service, as it allows you to write this sort of code very naturally. It depends on what you're doing, though... Python has some frameworks that work this way, although none so smoothly as what Erlang gives you. Tcl has also had this capability in its core for years, although, like Python, you have to be careful about writing 'blocking' code, something that you don't have to worry about so much in Erlang.

I would also recommend looking at node.js (http://nodejs.org/). Its an event based javascript framework that lends itself to the creation of scalable servers very easily. Its still early days, so might not be mature enough for your project, but worth a look.

The network service I'm developing is CORBA/ICE/RMI/... like. The difficulty is the request processing, not the I/O. I assume nginx may benefit from the fact that the different requests it has to process are predefined and limited in number.

Yeah, being fast is really easy if all you do is spit out files. When you actually have to do processing, things get a bit more difficult, and a system like Erlang becomes more compelling.

It all depends on what sort of compromises you want to make in terms of speed, ease of programming, and the expected amount of traffic, though.

I'm not sure about Erlang. I don't know this language and the protocol I designed uses binary encoding. Support of JS and python is planned, especially on the client side, but come with a performance overhead which is not very attractive when it comes to service performance.

Using a language you know is probably a good idea: better to get something up and running and worry about making it blazingly fast when you know you need to. Erlang handles binary data quite well, but if you don't know it, you don't know it.

One of big benefits of the async model that ngninx uses i that it can keep many open connections. If you don't have many long running open connections (I/O on the socket), then going that route doesn't really help as much.

Yes, being event based helps a lot, but the reason nginx is faster than other event based webservers is that it tries very very hard to add as little overhead as possible; For example not copying memory around unless absolutely neccessary.

(expanding on this) nginx uses a buffer-chain architecture internally. This means that if your data comes in chunks when you read it in (remember, nginx is event based) then it's stored internally in fragments that correspond to those reads. Almost all the operations on it work on those chains so often times the data never has to be copied until it's written (I believe using iovectors) back out. Memory is managed in request pools which minimize memory fragmentation, and are just faster/safer than calling malloc/free directly.