[jdc] 16-mar-2009] At times the wiki becomes slow. This can be reconstructed offline using the scripts at http://jos.decoster.googlepages.com/ex_slow.tar.gz What you'll need: * Tcl 8.6 (headd) * tcllib * mk4tcl * Wub (`svn -r 1481 checkout http://wub.googlecode.com/svn/trunk/ Wub`) After unpacking the `ex_slow.tar.gz` archive you may have to adjust the `auto_path`'s. first you'll nee to start the webserver. Go to the `ex_slow` directory and run the following command: tclsh ex.tcl To see the sloweness, I run this command 4 times in parallel from the `tests_slow` directory: tclsh get.tcl and from that same directory I also run: tclsh aget.tcl When the `aget.tcl` script completes, one or more of the `get.tcl` scripts stall. [LV] So, does it appear that the performance hit is occurring in the wub coding, or in the tcl interpreter? [jdc] 17-mar-2009 There was a race condition in [Wub], and [Wub] moved to event-driven output. Using the latest version of [Wub] from [svn] no longer has the problem. [CMcC] 22Mar09 there may still be a race condition, but moving to event-driven output also allows us to throttle input so we're not producing masses of it when the client isn't receiving. Some bots seemed to be prepared to send a lot of requests and not service responses, and this on many simultaneous connections. There was once an explicit limit on input connections, which limited this problem as a side-effect. Once the limit was removed, Wub became vulnerable to a kind of DoS. The effect of the request storm was only apparent when the client connection closed - at that point tcl had to free all of the data queued for that connection, during which time it could become unresponsive to events. This had a secondary effect, of forcing some bots to open even more connections, so there was a positive feedback loop. ---- !!!!!! %| [Category Tcler's Wiki] |% !!!!!!