[pmwiki-users] PmWiki scalebility questions (newbie)

Tom Lederer celok at gmx.net
Thu Oct 19 11:02:41 CDT 2006


Thanks for the offer. But i have an feeling that this is not the  
problem :)

in response to a grep -i "lock(" on the cookbook folder only the  
sectionedit.php has a Lock(2) and Lock(0), and the credits.php (from  
CreditsBlock) has a Lock(0). However all HandleEdit and  
HandlePostAttr calls are not listed.

Don't use to much time on this. I guess the issue is somewhere else.  
We will snoop and trace a little more tomorrow.

Best Regards,
Tom
-- 

Tom
http://www.celok.de


Am 19.10.2006 um 17:35 schrieb Patrick R. Michaud:

> On Thu, Oct 19, 2006 at 05:29:36PM +0200, Tom Lederer wrote:
>> Thanks. There are a some Lock(x)'s in cookbook and scripts... now we
>> are looking into those.
>
> If you can identify the cookbook scripts that are using Lock(),
> I could quickly take a look at them for obvious issues...
>
> Pm
>
>
>> Am 19.10.2006 um 16:25 schrieb Patrick R. Michaud:
>>
>>> On Thu, Oct 19, 2006 at 03:22:21PM +0200, Tom Lederer wrote:
>>>> Thanks for the enlightenment. Assuming that indeed a recipe causes
>>>> the locks: can anybody tell me how to look for the right terms to
>>>> find the recipes that use the flock?
>>>>
>>>> I.e. is it a special php function that i can grep for?
>>>
>>> Try looking for either "Lock("  (the PmWiki function) or
>>> "flock("  (the PHP function).
>>>
>>> Also, are you able to confirm that it's the saving of pages
>>> that is causing the delays in displaying the page?  I.e.,
>>> that no pages can be read or displayed while a page save
>>> is taking place?
>>>
>>> Pm
>>>
>>>>> On Thu, Oct 19, 2006 at 02:16:00PM +0200, Tom Lederer wrote:
>>>>>> i kinda re-open this thread. Having a relatively large wiki
>>>>>> (wiki.d:
>>>>>> 33 MB in 5000 pages, Version 2.1.11 (Doh!)) running and facing  
>>>>>> some
>>>>>> performance issues lately, we think we discovered a problem with
>>>>>> the
>>>>>> flock file. So i would like to know if we are correct and how to
>>>>>> improve.
>>>>>>
>>>>>> From what we learned the situation seems to be like this:
>>>>>>
>>>>>> Every page access process sets a read lock (with flock). Now if a
>>>>>> page should be changed, the writing process needs to wait for
>>>>>> all old
>>>>>> reading processes to end, and does not allow any new reading
>>>>>> processes to set a lock.
>>>>>
>>>>> While PmWiki once worked this way a very long time ago (April  
>>>>> 2005,
>>>>> prior to 2.0.0), it doesn't any longer.  Simply reading or
>>>>> accessing a page doesn't require a lock -- locks are set only
>>>>> when writing a page.
>>>>>
>>>>> So, if a page should be changed, the writing process only needs to
>>>>> wait for any other writing processes to end, and none of the
>>>>> read processes are blocked.
>>>>>
>>>>> (Of course, a recipe might be misusing the lock file and setting
>>>>> a read lock on every page access, but the PmWiki core doesn't
>>>>> do this.)
>>>>>
>>>>>> Is it possible that this results in page request times of several
>>>>>> seconds (1-30)?
>>>>>
>>>>> Not likely.  There must be something else that is causing the  
>>>>> delay.
>>>>>
>>>>>> Can performance be improved by introducing per-group lock files?
>>>>>
>>>>> Per-group lock files don't really help here -- whenever a page
>>>>> is saved, we're actually writing pages across several groups
>>>>> (e.g. Site.AllRecentChanges, .pageindex, .notifylist), and this
>>>>> will only increase once we add some of the commenting and
>>>>> blogging features.
>>>>>
>>>>> Pm
>>>>>
>>>>
>>>>
>>>
>>
>>
>





More information about the pmwiki-users mailing list