Perhaps we should begin to look at this at a webserver level. Perhaps
the webserver is blocking and can only handle one request at a time.
Try testing this on a variety of webservers. Apache, lighttpd, nginx...
I think Apache used worker processes, and I know that nginx does. So it
may be a good idea to debug this on different numbers of worker processes.
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com
--It's Wiki-Tools subgroup (http://wiki-tools.com
--The ElectronicMe project (http://electronic-me.org
-And Wikia ACG on Wikia.com
Daniel Barrett wrote:
I've confirmed that one slow MediaWiki page (due
to a slow extension) blocks the
entire webserver from serving any other MediaWiki pages. Not just a single session.
This is on CentOS 5 Linux with PHP 5.1.6 and MediaWiki 1.13.0.
1. Hit a wiki article that uses my <wait> tag (previously described)
that sleeps for 20 seconds.
2. Ask another user on another PC to hit any wiki page during those 20 seconds.
The wiki is unresponsive during those 20 seconds. As soon as the <wait> ends,
other pages can be served.
Any idea why this would be?
Long-lived extensions are realistic, e.g., those that hit an external resource
that is slow to respond.
"Session data is usually stored after your script terminated without the
need to call *session_write_close()*, but as session data is *locked* to
prevent concurrent writes *only one script may operate on a session* at
any time. When using framesets together with sessions you will
experience the frames loading *one by one due to this locking*. You can
reduce the time needed to load all the frames by ending the session as
soon as all changes to session variables are done."