jdc 16-mar-2009] At times the wiki becomes slow. This can be reconstructed offline using the scripts at https://wiki.tcl-lang.org/_repo/htmlfiles/ex_slow.tar.gz
What you'll need:
After unpacking the ex_slow.tar.gz archive you may have to adjust the auto_path's.
first you'll need to start the webserver. Go to the ex_slow directory and run the following command:
tclsh ex.tcl
To see the slowness, 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.