On Fri, 19 May 2006, Ivan Voras wrote:
If I was working on a project such as Apache I know I wouldn't be
concentrating of performance with prefork in this day when threaded modes
are where Apache has been aiming for modern high performance web serving
for a fair while now.
Did you miss discussions about how FreeBSD's threading sucks? Ok, "sucks" is
maybe a too strong strong word, but if you look for recent discussions about
MySQL, you'll see that the difference between Linux and FreeBSD performance
is huge.
BTW, there seems to be a fundamental misunderstanding of the benefits of
threading in the application developer community. Threading is actually worse
for performance for a number of application cases. These tend to be cases
where the kernel data structures shared across threads are accessed intensely
across a pool of threads that actually could operate with greater
independence. For example, pre-forked web servers vs pre-threaded web
servers. If relatively little computation takes place, and it's all a series
of accept()/send()/sendfile()/close() operations in many threads, you pound
the locks protecting file descriptor state in the process. If it were
different processes, the file descriptor state wouldn't be shared, so
performance would be greater, even though the context switch cost is greater.
I've observed this in micro-benchmarks on a number of OS platforms.
Threading is good for application performance where a high level of sharing is
absolutely necessary -- worker threads working on shared data in a shared
address space, passing file descriptors between them, lots of synchronization,
etc. In many other cases, it's not only not a benefit, but a significant
overhead.
Robert N M Watson
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
