Instiki devel - Sep 2005 - Caching strategy - just caching pre-rendered pages not enough

I finally got to the point of trying to run Instiki AR branch on a 
reasonably large amount of data.

As I always knew, merely caching prerendered pages is not sufficient. 
Basically, rendering is required to establish which page references 
which, as well as categories.
Therefore, every attempt to display All Pages, or Recently Revised takes 
several minutes. Too much, even if we cache it all.

What I am going to do then is to create tables page_categories and 
references:

create table page_categories (
  number id,
  number page_id,
  varchar category
)

create table references (
  number id,
  number page_id,
  varchar referenced_page_name, -- it has to be by name because of 
"wanted page" links
  char reference_type
)

where reference type can be L (linked page), W (wanted page) or I 
(included page)

PageRenderer instance will be able to return lists of Reference and 
Category objects after rendering a revision. Page#revise will clear old 
entries (if any) and insert new ones. It will also update
''Wanted''
references to ''Linked'' ones for a particular page.

Thoughts?

Alex

Alexey Verkhovsky wrote:
> What I am going to do then is to create tables page_categories and 
> references:
Done. Avoided creation of a separate page_categories table by making it 
a wiki_references row with link_type = ''C''.
Performance of All Pages and Revised Pages is now reasonable (since 
there is no more rendering involved), at least for a 70-pages wiki that 
I am testing with.

Rendering of includes is broken.

The next step regarding performance is to properly implement page 
caching (and sweeping) for everything, especially show and RSS feeds.

Alex

Alexey Verkhovsky wrote:
> The next step regarding performance is to properly implement page 
> caching (and sweeping) for everything, especially show and RSS feeds.
Done! Gosh, this was embarrasingly easy :)

Alex