Hi,
On 4/13/07, Steven Grimm <[EMAIL PROTECTED]> wrote:
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.
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.
Indeed, when HW has several CPUs or cores, etc, starts the business
case for using multi-threading designs despite locking and etc weird
issues to overcome.
Multiprocess designs have pros and cons to consider:
- pros are sometimes higher robustness, when several processes
are doing jobs in parallel; if a single process fails only a portion of the
load goes away (apache design);
- cons are issues with on-fly reconfiguration and management of such
multi-process entities.
My preference is towards multi-threaded rather than multi-process
architecture, where robustness may be enhanced by other means, like
keeping all essential data-structures in memory-mapped file, etc.
Y may wish to look for design using Leader-Followers design pattern
and optimize the number of threads experimentally, where the optimum is in many
cases 2-5 times multiple of CPUs number.
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...................................................................
Navigare necesse est, vivere non est necesse
...................................................................
http://curl-loader.sourceforge.net
An open-source HTTP/S, FTP/S traffic
generating, and web testing tool.
_______________________________________________
Libevent-users mailing list
[EMAIL PROTECTED]
http://monkey.org/mailman/listinfo/libevent-users
