On Sun, Oct 2, 2011 at 11:58 AM, Joerg Sonnenberger <jo...@britannica.bec.de > wrote:
> On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote: > > http://bulk.fefe.de/scalable-networking.pdf > > Please don't base decisions on questionable micro-benchmarks. fork+exec > is significantly more expensive than thread creation in a > multi-processor environment. i suspect that most of fossil's network use is CGI mode, not standalone server (or in local ui mode with a single user). The fork() only happens in server mode (which then spawns off into what we know as CGI mode), meaning that any migration from forking to threading would only happen in the server, and would add undue complication to code which is otherwise straightforward (and which doesn't have any need to scale to 1000 requests/second). @Paul: thanks for the article. It's a bit dated (2003), but nonetheless interesting. i can report that the fork() do not appear to be a problem at the level fossil operates. It is a special-purpose app, not a generic server serving arbitrary content. i.e. it gets fewer requests and when it gets a request it doesn't have to do much work to figure out what to do - the request path leads directly to C code instead of arbitrary content which must be figured out. My 32-bit netbook (1.6GHz Atom) regularly responds to fossil/json requests over CGI in under 50ms and my 64-bit laptop/workstation (2.4GHz Core2 Duo) averages under 20ms for most of the current JSON APIs (/json/stat in "full detail mode" can take several seconds on a large repo). -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
