"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."
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (
)
--Games-G.P.S. (
Daniel Barrett
wrote:
> It seems that one slow extension can bring MediaWiki to a halt. For
> example, if you define a <wait> tag that simply sleeps for 20
> seconds, and you hit a page that contains it, no other MediaWiki
> pages can be served during those 20 seconds.
>
Brion Vibber writes:
I did a quick test with this on my local wiki; it
looks like it may be
session-related.
If I preview a page with <wait>20</wait>, then go load something up in
another tab in the same browser, it sits there waiting on both tabs.
(Confirmed with Firefox 3 and Safari 3 on Mac OS X.)
If on the other hand I go load things up in another browser, there's no
delay there.
Interesting.
I tried this on our site, and using multiple browsers/sessions made no difference.
Using Firefox 2 from host1 (hitting the <wait> page) and lynx from host2 (hitting
any
other page), both browsers waited the full 20 seconds.
And indeed, it appears that PHP session files are
by default locked to
prevent multiple simultaneous accesses.
Is this a PHP issue or a MediaWiki issue, and is there a workaround?
Should this be filed as a "priority 1" bug? Many of our users
are getting timeouts due to this problem, ever since we upgraded to 1.13
from 1.12.
Thanks,
DanB