Richard, Agree with all you say, it reflects my frustrations about a profession where "simple, stable and reliable" is so readily dismissed as outdated.
Re your specific comment "I'm not sure why the one-process-per-task model has fallen out of favor.". It may be because early web servers (and Apache in particular) struggled to scale on the then available hardware. That and (as you mention) the startup cost of the languages being used. Re SCGI, while I agree with all you say my experience is that it isn't difficult at all (at least, from Tcl). In the Einstein Brain Atlas project we use NGINX + SCGI and it works just fine and is relatively simple to integrate with Tcl. Not that I'm advocating SCGI for Fossil, but if you do have needs that go beyond what simple CGI can provide then Nginx/SCGI is a relatively small incremental complexity cost. Steve On 29/05/2013, at 10:01 AM, Richard Hipp <[email protected]> wrote: > > > On Wed, May 29, 2013 at 10:09 AM, Stephan Beal <[email protected]> wrote: > On Wed, May 29, 2013 at 3:59 PM, <[email protected]> wrote: > Despite my error, I find the simplicity of setting up a Fossil repo > (or better a set of repos) under cgi fantastic. > > +1 > > @Richard: out of historical interest, what was the motivation behind adding > CGI support initially? (Despite CGI being archaic, it was _the_ feature which > caused my initial addiction to fossil.) > > > Well, I suppose I don't consider CGI to be archaic. CGI is simple, concise, > easy to administer, easy to implement (on both ends), efficient, and is > supported by all web-servers (except nginx). > > CGI grows out of the historic development model where you spin up a new > process to handle each specific task. Unix was built around this model. It > is an older model, but just because it is old doesn't make it bad. There is > really quite a lot to recommend it: > > (1) No need to worry about resource leaks because the operating-system > automatically and efficiently reclaims resources when the short-lived working > process dies. > > (2) Programming is much simpler because you can almost always run > single-threaded and you can often get away with using global variables. > > (3) Unit testing and debugging is easier since the worker task is now an > independent process that can be run from a command-line prompt and/or in gdb > or valgrind. > > (4) Bugs in the application are well-contained. One worker task might > segfault due to a bug, but other independent tasks continue happily running > without impact. > > (5) There are no background processes that an administrator needs to monitor > and keep running. The worker tasks are launched on-demand. Thus the > administrative overhead is reduced. > > I'm not sure why the one-process-per-task model has fallen out of favor. One > cause might be a quest to squeeze every last ounce of performance out of > systems by avoiding the process creation and breakdown overhead. Another > reason might be people growing up in a windows-oriented world where process > creation and breakdown is significantly more complex and costly compared to > unix where fork() and exit() are easy and cheap. > > I like things to have low administrative, development, and maintenance > overhead. CGI fits that requirement nicely. Other similar technologies > (FCGI or SCGI come first to mind) require a lot more effort to program, to > set up, and to maintain. Those others might be slightly faster on a busy > site, but CGI is "fast enough" for most applications, especially for small > and light-weight applications. For something like Fossil, FCGI/SCGI would be > no faster. (FCGI/SCGI might well be much faster if your CGI script starts > with #!/usr/bin/perl or #!/usr/bin/php, but that is a function of the > start-up overhead of your scripting language, not of the interprocess > communication protocol. Fossil, being native code, starts up very quickly > and so CGI startup time is minimized and the performance advantages of > FCGI/SCGI are lost in the noise of the added complexity.) > > The Fossil and SQLite websites spin up about 4 or 5 new worker processes per > second on a debian linux VM at Linode.com that is a 1/24th slice of an actual > server. And yet the load average stays down around 5%. People say "Oh, you > could go so much faster using $COOL_NEW_TECHNOLOGY". But I doubt it. And > even if we could, with the load average holding steady at 5%, it isn't worth > the trouble. Better to keep things simple and reliable. > > -- > D. Richard Hipp > [email protected] _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
