4 ms·
Depends on what you're doing. I read that article a couple years ago and thought "Take that you libevent C zealots." And while I still firmly believe that the J
by JoelPM 16y ago
Depends on what you're doing. I read that article a couple years ago and thought "Take that you libevent C zealots." And while I still firmly believe that the JVM is optimized and mature enough to hold its own against platforms that have traditionally been considered faster, I still think there are cases where event-based I/O will out-perform thread-per-request. For instance, if most of what you're doing is shuttling bytes back and forth (like in a proxy). I also wouldn't be surprised if a thread-per-request app took a bigger hit when virtualized (like EC2) than an event-based app.
- agazso 16y agoIf you start a thread for each request in Java, you can easily run out of memory when serving large number of connections. This is because Java uses kernel threads, and the stack of threads are allocated from heap when created, usually around the size of 1MB. This means that you will need around 10GB of memory when serving 10000 request, while an event based app can serve the same amount of requests with minimal memory. You also have to take into account that thread creation and context switching is really an expensive operation (contrary what the OP is saying), so the thread-per-request app is adequate only for serving small number of requests but for large numbers you will need to use the event-based approach. You might get along with a threadpool based approach, but take into account that if your protocol is not stateless, then you will need shared state which means you have to use concurrent data structures, which might complicate code.