[pmwiki-users] PmWiki seems to "hang" on overloaded boxes

Joachim Durchholz jo at durchholz.org
Sun May 22 15:22:34 CDT 2005


Patrick R. Michaud wrote:

> On Sun, May 22, 2005 at 06:10:09PM +0200, Joachim Durchholz wrote:
> 
>> Patrick R. Michaud wrote:
>> 
>>> At 08:11 AM 5/22/2005, Joachim Durchholz wrote:
>>> 
>>>> Here's what happened: PmWiki suddenly started to "hang", i.e. 
>>>> it would not respond at all, or display only part of the output
>>>> and "hang". With "hang", I mean that the browser still has the
>>>> data-is-forthcoming animation, but no new data ever arrives. 
>>>> (For an "forever" value of one or two minutes.)
>>> 
>>> First and most importantly, what version of PmWiki?
>> 
>> 2.0beta28.
> 
> Yup, that's likely the issue.  There may also be issues with
> interactions between session-based authentication and the .flock
> file; beta30 takes care of these also.

Ah, I didn't know that.

Would that apply to the situation at hand? That wiki is configured with
the same password for 'admin', 'edit', and 'upload' (i.e. nothing
fancy); I don't know whether that's cookie-based or session-based auth.

>>> Second, note that by the time PmWiki is outputting information to
>>> the browser, PmWiki has pretty much completed any "real work"
>>> that needs to be done and is simply doing lots of print
>>> statements.
> 
>> Hmm... I had at least one occasion when PmWiki had output the
>> header and left sidebar, but didn't output the right sidebar and
>> main content. (For that specific skin, the output order is header
>> -> left sidebar -> right sidebar -> page, via CSS.)
> 
> FWIW, in terms of "when things are converted to HTML", it's page, 
> header, left sidebar, right sidebar.

Hmm... not sure what you mean here. The template in question has a CSS
layout, and the template code lists both sidebar sections before the
main page section, so I'd gather that's the order in which things are
being processed.

I definitely had a browser window with a header and a left sidebar, and
nothing else.
My best theory is that the main page was rendered (converted to HTML)
first, then started to output, found it had to include the left side
base, managed to render and output that, then found the right side bar,
and died sometime during rendering. Of cousre, not knowing the exact
order in which PmWiki processes things, I might be totally wrong here,
so I'm happy with any clarifications and corrections for that picture :-)

>> No, I'll have to upgrade. I wasn't too happy with the ramifications
>> of some of the announced changes (not sure anymore which ones, but
>> there were some), so I decided to stop upgrading unless necessary.
>> 
> 
> Totally understandable -- I just know that beta28 and beta29
> substantially increased the potential for deadlocks to develop, which
> is why I redid the locking system for beta30.

I didn't know that. (I seem to be repeating myself... *gg*)

Now that everybody seems to be happy with beta30, it seems best to
upgrade anyway. Satisfaction has slightly declined, and I don't want
that trend to continue... and if beta28 became less stable than usual,
then beta30 has a real chance to work better.

>> On a tangent, what's the best way to see how much time a page took?
> 
> The diag.php module includes a "stopwatch" function that can give
> some idea of how long things are taking -- see, for example, the
> bottom of 
> http://www.pmwiki.org/wiki/Main/AllRecentChanges?skin=stopwatch .

Works, thanks.
Documented in PmWiki.OtherVariables and Cookbook/SkinGuidelines.


Two buglets I noted in passing:

The first call to StopWatch is done immediately at the start of
pmwiki.php, before config.php had a chance to set it. It might be a
better strategy to collect raw timing data as returned by PHP, and
postpone the (more CPU-intensive) formatting to DisplayStopWatch().

The 'varlink' pattern (in scripts/vardoc.php) says $WikiWordPattern to
determine what a valid PHP variable name is, and that's a bit too
strict: it doesn't recognize (for example) the $Skin variable.

Regards,
Jo



More information about the pmwiki-users mailing list