(Another) simple benchmark
Robert Watson
rwatson at FreeBSD.org
Sat May 20 17:21:47 UTC 2006
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
More information about the freebsd-performance
mailing list