/* * Copyright (c) 2000-2006 Alberto Reggiori * Dirk-Willem van Gulik * * NOTICE * * This product is distributed under a BSD/ASF like license as described in the 'LICENSE' * file you should have received together with this source code. If you did not get a * a copy of such a license agreement you can pick up one at: * * http://rdfstore.sourceforge.net/LICENSE * */ Tried sofar fork per database, select loop preforked per database, select loop fork per connection, add locking thread per connection, cheaper locking thread per database, cheaper switching Conclusions sofar on BSD fork/dbase is good compromise; thread per database is about the same speed but more overhead. thread per connection is faster for few connections, but has a lot more overhead. Forking sofar scales best < mmlimit. Above that thread per connection is best, but by far best is single select loop per database. Files children.c fork and msg passing children_trd.c thread; no msg passing children_ltr.c NSPR treads, msg passing deamon.c Handles fairly efficient read/write to a socked. Without blocking where needed. handler.c simple call outs to libDB The nasty exception is get_dbp() which has some funny return values due to the internal fork() or pthread attaching. loop.c main select loop loop_conn.c main wait loop treaded case main.c process kick off mymalloc.c debugging malloc. pathmake.c misc. There are a couple of not so obvious optimizations where we build explicit tables or pointer lists to avoids doing for loops through lists of arrays; often at the expense of a some memory. Secondly we use some funny struc's which are linked and created in a way to kind of blow not to many caches if possible. The only big remaining niggle is that we should collapse more functions into just a few; as to get the heap/stack both as shallow as possible. As this seems to speeds up the NSPR and Pthreads greatly.