Difference between revisions of "User:TerryE/phpBB3.0.4 Migration/Cron tasks"

From Apache OpenOffice Wiki
Jump to: navigation, search
(New page: = Cron Tasks = A placeholder for '''cron'''-like functioning in phpBB. * The reason for this is that the '''common.php''' includes the following conditional which causes the '''cron.php'...)
 
(Cron Tasks)
Line 1: Line 1:
 
= Cron Tasks =
 
= Cron Tasks =
  
A placeholder for '''cron'''-like functioning in phpBB.
+
PhpBB has to carry out a number of periodic housekeeping tasks, the sort of thing that you would typically use cron for on a Linux system.  These the following:
 +
* Processing email queue every 'queue_interval'
 +
* Garbage collecting on the cache
 +
* Garbage collecting on the database
 +
* Garbage collecting on the search tables
 +
* Garbage collecting on the sessions tables.
  
* The reason for this is that the '''common.php''' includes the following conditional which causes the '''cron.php''' task to fail in our shared code implementation, since this causes it to attempt to resolve the cache directory in '''/var/www/phpBB-common/cache''' which doesn't exist.  What the logic for doing this, heaven knows, but my work-around is to reset '''$phpbb_root_path''' back after including this in the cron.php routine.
+
However as the implementation can rely on cron being available, and since some of these activities are pretty processing intensive, it isn't reasonable to appended this processing as a synchronous step in a rotuine page transaction.  phpBB therefore uses a trick that exploits the fact that most browsers implement a lazy image load policy during the page load. Hence the 'cron' processing is a dummy image generator which ultimately returns a one blank pixel image, but in reality this implements a callback from the browser to initiate the cleanup function. This doesn't noticeably the user experience during this delayed image load during the page load.
if (defined('IN_CRON'))
+
{
+
    $phpbb_root_path = dirname(__FILE__) . DIRECTORY_SEPARATOR;
+
}
+
  
 
The way the cron hook is executed is that the footer template includes the hook:
 
The way the cron hook is executed is that the footer template includes the hook:
Line 36: Line 37:
 
   }
 
   }
  
What this ladder does is that when one of these thresholds has passed the page includes a image link to a dummy image which is one blank pixel, but in reality this triggers the cleanup function.  This trigger occurs at page load but most browsers implement a lazy image load so this doesn't impair the user experience.
+
== Cron Bug ==
  
I have put in this fix, but also set the '''email_package_size''' parameter to zero for now.  I will review this for tuning and optimisation later, but for now this works.
+
'''cron.php''' like all other phpBB transactions imports '''common.php''' to set up a common cote.  However this include contains the following conditional which causes the '''cron.php''' task to fail in our shared code implementation, since this causes it to attempt to resolve the cache directory in '''/var/www/phpBB-common/cache''' which doesn't exist.  What the logic for doing this, heaven knows, but my work-around is to reset '''$phpbb_root_path''' back after including this in the cron.php routine.
 +
if (defined('IN_CRON'))
 +
{
 +
    $phpbb_root_path = dirname(__FILE__) . DIRECTORY_SEPARATOR;
 +
}
 +
I have put in a fix for prevent this overright and now the cron tasks work properly, but for now I have also set the '''email_package_size''' parameter to zero.  I will review this for tuning and optimisation later, but for now this works.

Revision as of 23:08, 19 May 2009

Cron Tasks

PhpBB has to carry out a number of periodic housekeeping tasks, the sort of thing that you would typically use cron for on a Linux system. These the following:

  • Processing email queue every 'queue_interval'
  • Garbage collecting on the cache
  • Garbage collecting on the database
  • Garbage collecting on the search tables
  • Garbage collecting on the sessions tables.

However as the implementation can rely on cron being available, and since some of these activities are pretty processing intensive, it isn't reasonable to appended this processing as a synchronous step in a rotuine page transaction. phpBB therefore uses a trick that exploits the fact that most browsers implement a lazy image load policy during the page load. Hence the 'cron' processing is a dummy image generator which ultimately returns a one blank pixel image, but in reality this implements a callback from the browser to initiate the cleanup function. This doesn't noticeably the user experience during this delayed image load during the page load.

The way the cron hook is executed is that the footer template includes the hook:

 <!-- IF not S_IS_BOT -->{RUN_CRON_TASK}<!-- ENDIF -->

The page_footer setup function has an optional parameter $run_cron which defaults to true, and in fact is always called page_footer(), so this cron path is executed on every page generation. The code is (I've compressed its layout to save space):

 $cron_type = ;
 if ( time() - $config['queue_interval'] > $config['last_queue_run'] && 
      !defined('IN_ADMIN') && 
      file_exists($phpbb_root_path . 'cache/queue.' . $phpEx))             { // Process email queue
     $cron_type = 'queue';
 } else if (method_exists($cache, 'tidy') && 
            time() - $config['cache_gc'] > $config['cache_last_gc'])       { // Tidy the cache
     $cron_type = 'tidy_cache';
 } else if (time() - $config['warnings_gc'] > $config['warnings_last_gc']) {
     $cron_type = 'tidy_warnings';
 } else if (time() - $config['database_gc'] > $config['database_last_gc']) { // Tidy the database
     $cron_type = 'tidy_database';
 } else if (time() - $config['search_gc'] > $config['search_last_gc'])     { // Tidy the search
     $cron_type = 'tidy_search';
 } else if (time() - $config['session_gc'] > $config['session_last_gc'])   {
     $cron_type = 'tidy_sessions';
 }
 if ($cron_type) {
     $template->assign_var('RUN_CRON_TASK',
                           '<img src="' . append_sid($phpbb_root_path . 'cron.' . 
                                                     $phpEx,'cron_type=' . $cron_type) . 
                           '" width="1" height="1" alt="cron" />');
 }

Cron Bug

cron.php like all other phpBB transactions imports common.php to set up a common cote. However this include contains the following conditional which causes the cron.php task to fail in our shared code implementation, since this causes it to attempt to resolve the cache directory in /var/www/phpBB-common/cache which doesn't exist. What the logic for doing this, heaven knows, but my work-around is to reset $phpbb_root_path back after including this in the cron.php routine.

if (defined('IN_CRON'))
{
    $phpbb_root_path = dirname(__FILE__) . DIRECTORY_SEPARATOR;
}

I have put in a fix for prevent this overright and now the cron tasks work properly, but for now I have also set the email_package_size parameter to zero. I will review this for tuning and optimisation later, but for now this works.

Personal tools