Optimize maintenance

[dartar]

(reported by |Sam| on #wikka, writeup by me --JavaWoman)

Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in wikka.php executed by the main Run() method. However, there is an extra condition here:

if(!($this->GetMicroTime()%3)) $this->Maintenance();

I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman

That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX

Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith

Since page_purge_time is counted by days, the maintenance should be done daily. Wikka should store somewhere the date of last Maintenance performed. Then Run() should compare this value with the date of script execution and if different, performs maintenance. Another good solution would be to place the maintenance in another script. For example, maintenance.css.php located in /handlers/page. For webmasters that have cron job, they can directly schedule it by cron jobs. (http://wikkasite/HomePage/maintenance.css). For others, Wikka could insert a line <link rel="stylesheet" type="text/css" href="http://wikkasite/HomePage/maintenance.css" /> in wikka page if the maintenance hasn't yet been performed that day. The advantage is that Maintenance operation does not slow down the page generation time.

Related tickets

#93

[vincent.fretin@…]

Wikini use:

if(!($this->GetMicroTime()%9)) $this->Maintenance();

I don't know if Maintenance() is executed more often or not.

[JavaWoman]

Replying to vincent.fretin@gmail.com:

Wikini use: if(!($this->GetMicroTime()%9)) $this->Maintenance(); I don't know if Maintenance() is executed more often or not.

It won't make much difference - the condition will almost never be true: The method GetMicroTime() returns as a float (always has done, ever since release 0.1 of Wakka!) - the chance that this will actually represent a whole (integer) number that is divisible by 3 (or 9) is actually very, very small.

A microtime as a float is fine for calculating page load times, but not such a good method to decide semi-randomly whether or not something is to be done.

I was looking at replacement of the GetMicroTime() method (because wikka.php already has an equivalent one) and came across this usage. I agree with this analysis in the ticket description:

Since page_purge_time is counted by days, the maintenance should be done daily. Wikka should store somewhere the date of last Maintenance performed. Then Run() should compare this value with the date of script execution and if different, performs maintenance.

In other words: Maintenance() should always (or at least often) be called, and itself decide whether page_purge_time has elapsed already, if not, return immediately. Of course, this would make implementation of #98 (leave a certain amount of history at all times) even more important: this ticket should not be implemented until #98 has been!