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

Joachim Durchholz jo at durchholz.org
Mon May 23 11:19:18 CDT 2005


Patrick R. Michaud wrote:

> On Sun, May 22, 2005 at 10:22:34PM +0200, Joachim Durchholz wrote:
> 
>>> 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.
> 
> Session-based auth is a cookie-based auth.

OK, then let me clarify my question: since you were careful to say
"session-based auth", is there any non-session-based auth?

>>> 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.
> 
> PmWiki first converts the main page contents to HTML first, then it 
> begins sending the template.  When it encounters any <!--wiki:...--> 
> items in the template, they're converted into HTML at that point.

OK, then it's probably that PmWiki stalled while processing the rightbar.

I'll have to do some load testing (in my copious free time *sigh*...)

>> 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().
> 
> I originally tried doing it this way, but it turns out that
> collecting and storing the raw timing data ends up being about as
> much work as formatting it.

OK, then here's another proposal: Initialise $EnableStopWatch with 2
initially, then set it to 0 immediately before calling config.php. That
way, any measurements before configuration will be collected.

Right now, the initial StopWatch() call in pmwiki.php will be blocked
because $EnableStopWatch is unset. (On rereading my post, I see I missed
to mention $EnableStopWatch. Sorry for posting unclear bug reports.)

I still think it's a good idea in general to store raw data instead of 
formatted data, since it's easier to process for any scripts that may 
want to access it, but in the case of StopWatch that probably isn't 
worth the trouble :-)

>> 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.
> 
> Yes, I'm just not sure I want to reduce its strictness for the sake 
> of the few non-wikiword variables that exist.

You have my vote *for* doing so. Reserving $[a-zA-Z]+ for PHP variable
names does make sense within pmwiki.org. Particularly short-named
variables such as $Skin tend to more central than the average variable,
so it's a Good Thing if they get hyperlinked.
Outside of pmwiki.org, it might be a good idea to keep the $<something>
syntax reserved for local recipe use. (I could imagine that any site
heavy on Perl or PHP might want to activate the $ syntax as well, but
others will probably want to do something else or nothing at all with it.)

Regards,
Jo



More information about the pmwiki-users mailing list