[pmwiki-users] Speed up PmWiki
thomas.bley at simple-groupware.de
Tue Aug 14 18:15:49 CDT 2007
Patrick R. Michaud wrote:
> ...but in the code given by PITS.00966, the value being written
> to the "cache file" is the result of MarkupToHTML(), yes?
> That would seem to imply that none of the skin, sidebar, pageaction,
> or other items are being saved in the cached .html file, and
> displaying that .html file directly would lose all skin
> and header information...?
The code may be incorrect in this case, it should save the complete page
to a file. E.g. in 2.1.10 I used:
$out = ob_get_contents();
But there may be better methods for doing it.
> It's very difficult to keep track of dependencies correctly --
> and I think it's unrealistic for authors to do this manually
> and reliably. Also, if I'm reading it correctly, the approach
> being described seems a bit backwards, in that if pages A, B,
> and C depend on page Y, I have to keep track of that fact
> inside of page Y. And if I add a page D that depends on X, Y, and
> Z, I have to remember to update the (:static ...:) list in each
> of those pages.
For these complex scenarios it won't be helpful to use static caching.
But for easy cases like page summaries (PITS, newstickers, etc.) it will
> Part of the assumption for caching is that updates are relatively
> infrequent. So, "costs a lot of performance" is purely relative.
Yes that's true. There are a lot of parameters that take place here.
Number of users, number of updates, number of dependencies, etc.
That's why the (:static :) setting might be good: Users can decide on
the own where they want to optimize. E.g. if half of the traffic goes to
the first page, people might optimize it with a static html page and
refresh it once every hour (:static active=on expires=hour:).
> One very important point to note about the mod_rewrite approach
> is that it completely bypasses any ability to perform authorization
> checks. So, the code that saves the HTML version of the page needs
> to do so only if there are no page restrictions on the page.
> And any modifications to GroupAttributes need to invalidate
> all of the cached pages in the group.
In many cases, the performance problem is an uncontrolled high number of
anonymous users (press releases, tv ads, etc.).
So taking them out of the CPU load gives more resources for the editors.
All in all I think static caching can help to improve special parts or
even (in my case) the whole page.
More information about the pmwiki-users