On Thu, Dec 31, 2009 at 10:35:38AM +0100, Pierre-Yves Kerembellec
<py.kerembel...@gmail.com> wrote:
> Thanks for the thorough explanation. I'm actually developing a fast socket
> server that will be using a storage backend library to store thousands of
> millions of "small objects" (basically less than 1K) in a large optimized
> hash table. This storage layer maintains a large objects cache in memory
> (so to not hit the HD again on next read for the same object), this memory
> cache not being share-able across processes.
If it isn't sharable across processes (using, well, shared memory) then
it's not sharable between threads either, me thinks. The difference is
simply that threads force shared memory for everything.
Now, threads will likely be slower, but easier, since pthreads offers
portable and widely-implemented inter-thread locking, while e.g.
posix/pthread inter-process locking is not as widely implemented.
> FYI I followed your previous advice and already migrated to a lightweight
> memory queue + simple pthread mutex + ev_async_send(), instead of
> using pipes. The performance gain is substantial (I went from 15kreq/s to
> 19-20kreq/s up, i.e. more than 20% improvement), and it seems the whole
That's great to hear :)
> server uses less CPU in general (less system calls and kernel/user-space
> switches I guess). I've tried playing with thread/core affinity, but no
> conclusive
> result sofar.
As long as your workers do little to shared (or unshared) data structures,
do not change machine state too often, then threads shouldn't do badly at
all, and will be about as difficult, or easier, than using processes.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / p...@goof.com
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
