I recently worked with a WordPress MU installation. As an ease of deployment and probably because it is largely used on shared hosting which may not offer access to cron jobs, WordPress default way of processing its scheduled tasks is through front-end and admin page requests. As a result, everytime a page is requested, the system looks to see if there are jobs to run. When so a call is performed to execute the tasks. The asynchronous nature of the call makes it somewhat transparent from the webuser perspective.
Although it works well, I do not feel confident to use this mechanism on a site with a lot of traffic. After some google searches to find out how it works, I’ve read many stories about hosting companies denying access to wp-cron.php because of bad impact on their server.
I had another issue while using WP-SuperCache. Since the super cache is super because it prevents loading the whole PHP engine for guest requests. Unfortunately, no php code execution means no cron execution for super cached pages… Since the cron is responsible of cleaning the super cached files, they are served indefinetly or until a user logs in (logged users do not get super cached files).
So for all the good reason I had, I wanted to run WordPress cron jobs from a real cron schedule.33 comments
If some of you have been using PHP on Windows with SQL Server 2005, you may have hit some problems especially if you wanted to exploit new features of SQL Server 2005 like xml datatype, NVARCHAR(MAX), etc.
The driver that had the better support for these were the PHP ODBC wrapper combined with the SQL Server 2000 ODBC driver. The bad news is, by default, PHP ODBC uses server-side dynamic cursors which is the thing Microsoft says to avoid as much as possible (unless you have a need for that). It is very slow, server resource intensive, poor performing, etc.
Some succeeded to change the way ODBC were handling resultset by using a hint at connection time (SQL_CUR_USE_ODBC), but it didn’t help for us. Some perfectly valid parameterized queries where just giving unexpected results.
I even downloaded PHP’s source code to see why it was using dynamic cursors by default. If I could, at least, change the default cursor, we may had a little performance increase… It was hardcoded to “dynamic” with the following comment on top of it:
Try to set CURSOR_TYPE to dynamic. Driver will replace this with other type if not possible.
So next thing would be to change it and recompile… forgot about it!
Then, some time at the end of 2007, I discovered an alpha community preview release of a new driver made by Microsoft. Wohoo! This version was unstable with xml datatypes at a point that it was making my Apache server crash…
Fortunately, the official release finally got out et we are testing it for some time now! So far, there are no blocking bugs. The quality is good enough that I took the time to created a Creole wrapper (our web application uses Creole as database wrapper API) for it and start using it full-time on our develpment environment.
Here are some observations:
- On my laptop, based on a non-official, non-extensive performance test, I had a 400% to 500% performance boost for fetching 200 records of a large (numerous fields) table.
- UTF-8 support exists, but conversion must be done manually, field by field (better have a database wrapper API…) and at a huge performance cost.
- UTF-8 support works only for query parameters and resultset values. If you hardcoded a query filter (I know it is not a best practice, but we all supports legacy applications…) you will have to rewrite it with parameters or drop UTF-8 support.
- If you are using PHP from a Linux server, you are still left alone because the Microsoft driver relies on the ODBC SQL Server Native Client driver that works only on Windows.
*** UPDATE : 2009-02-04 ***
Thanks to Piotr initiative, a new creole driver is now available (under LGPL license) here: