Edgewall Software
Modify

Opened 19 years ago

Last modified 4 years ago

#1216 new enhancement

wiki pages caching

Reported by: zilvinas Owned by:
Priority: low Milestone: next-major-releases
Component: wiki system Version: devel
Severity: normal Keywords: objectstore performance
Cc: zilvinas@…, shanec@…, mmitar@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Most of the time wiki pages can be considered as a static content. So instead of generating and regenerating wiki pages → html output, perhaps it would be useful to cache generated HTML output of wiki pages on the disk. Next time, page is requested checking if there have been changes - if not serve the file, otherwise - regenerate HTML page and serve newly generated file.

Sure this raises a question, what to do with embedded python macroses (see wiki-macros). Having such functionality, would help to reduce server load and would be very helpful especially with wiki rst (Restructured Text extension).

This ticket is rather an attempt to find out if there is a demand for such functionality. Consider this ticket as a discusion starting point.

Attachments (1)

wiki_cache.patch (5.6 KB ) - added by mixedpuppy <shanec@…> 15 years ago.
experimental parital cacheing of wiki pages

Download all attachments as: .zip

Change History (13)

comment:1 by Christopher Lenz, 19 years ago

So… what about wiki macros? The content they generate could change anytime. Would only pages that don't contain wiki macros be cached?

comment:2 by anonymous, 19 years ago

The way I think is the following:

Wiki pages caching is optional (either enabled or disabled by default). Assuming caching is enabled, during wiki page serving it is possible to detect if wiki page makes use of macroses. (Searching for should be enough). Perhaps initial version, for simplicity, should not cache wiki pages with macroses in them.

In future, caching system can be smart enough always to execute macroses only without need to reproccess whole wiki page ? (execute macros, insert it's output at appropriate place in preprocessed wiki page and serve it … - perhaps that makes no sense).

comment:3 by Christian Boos, 18 years ago

Keywords: objectstore added

Also, note that idea of a cache could be expanded to other things as well, like changesets, fontified source files, …

Disk is cheap, and a kind of LRU cache of a few Gbytes could speed things up quite a bit…

comment:4 by Christian Boos, 17 years ago

Milestone: 2.0

comment:5 by Christian Boos, 15 years ago

by mixedpuppy <shanec@…>, 15 years ago

Attachment: wiki_cache.patch added

experimental parital cacheing of wiki pages

comment:6 by mixedpuppy <shanec@…>, 15 years ago

I've attached a hacked in cache for wiki output. It avoids cacheing macros unless there is a cache argument in the macro. With ApacheBench on my laptop, it reduced fetching WikiStart from 120-140ms to around 70ms.

comment:7 by mixedpuppy <shanec@…>, 15 years ago

Cc: shanec@… added

comment:8 by Christian Boos, 14 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:9 by Christian Boos, 14 years ago

Keywords: performance added
Milestone: triagingnext-major-0.1X
Priority: normallow

Could still be a long term goal (bordering unscheduled).

comment:10 by Mitar, 12 years ago

Cc: mmitar@… added

comment:11 by Ryan J Ollos, 9 years ago

Owner: Jonas Borgström removed

comment:12 by Rahul, 4 years ago

Here is my solution to LRU cache implementation in C++. LRU Cache there are various references I used to implement this Reference

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.