Martin Hedenfalk wrote:
I'm sorry if the above seems harsh, but I really don't see the point in implementing a multi-threaded libevent server.
I can answer that, since I converted memcached from single- to multi-threaded: even if each request completes in a very short time, pile enough of them up in a short period of time and you'll run out of capacity on one CPU. Adding threads lets you make full use of a multiprocessor machine without having to split your application up into separate processes. Splitting into multiple processes not only duplicates whatever constant overhead each instance of your app has, but if the application needs to have globally shared state, you're looking at something like a shared memory region or mmapped file with the same locking issues you have in a multithreaded app.
As for how to do it, my approach is documented on the libevent home page (or rather, there's a link there to my explanation) so I won't repeat myself. But I will say it's working well for us -- our memcached instances are handling close to twice the request volume they used to be able to handle when they were single-threaded, and they still have plenty of capacity to spare.
-Steve _______________________________________________ Libevent-users mailing list [EMAIL PROTECTED] http://monkey.org/mailman/listinfo/libevent-users
