SQL cacher

[quix0r]

First of all here is a list of what I have changed and why:

• Direct accesses on class fields replaced with getter/setter methods. This is about better security - currently only in Java but in PHP6, too! - and a better "design of code". There is a good guideline on Sun's webpage which you shall read and follow when you code object-orientated.

• Fetching RSS feeds on the dashboard can now sitched off by a constant. Put this one line to your wp-config.php:

define('DISABLE_RSS_FETCH', true);

You may need this if you want to use WP behind proxies installed on your company's workstation (*always* ask for permission! This can be a reason for getting fired). I will start another topic about this after I have finished this.

• Closing the database connection is implemented by a shutdown-function in wp-settings.php. This is always a good idea... ;-)

• SQL query cacher in alpha state added. This is my youngest baby and it shall reduce the number of queries on your database and increase the speed of your blog. Remember every request must be *send* to the database. Even when it is over a uni* socket (on Linux boxes the most case) its still slower than loading a "local" file. PHP needs to send the request over it's library to the SQL process, the SQL process loads some database files and processes them. Then the result got sent back to the PHP library.

Okay, you told me that your SQL queries are already optimized but 19 (!) SELECTs are still 19 queries and way too much for high-usage blogs.

Does someone know what kind of SQL statement (SELECT, UPDATE, INSERT or DELETE) is the most used? My opinion on this is SELECT.

Surely this cacher needs some improvement, including the compression methods. The functions gzcompress() and base64_encode() which are being used in my cacher are currently slowing down the blog too much. So let's have a look for faster PHP fucntions.

The cacher also has a built-in debugging function which displays some arrays. You can enable it with this:

define('DEBUG_SQL_CACHE', true);

The cacher itself can be enabled with this:

define('ENABLE_SQL_CACHE', true);

[quix0r]

The SQL cacher patch.

[westi]

-1 for this.

Surely you are just replicating the work of the mysql query cache.
Why the sprintf's when you can just use the standard php string creation code.

If you really think this makes your blog faster can you not do it by using the pluggable db stuff added for #2721 in [4153], [4154] and [4160]

Yes getters and setters are true OO but WordPress in general is not true OO and you are adding code for no real benifit.

You need to split out any other individual changes into seperate tickets (for example the RSS Fetch disabling).

[masquerade]

-1 for a few reasons.

First and foremost, the built-in WP object cache will achieve much of the same purpose, with a more pluggable backend. A few queries are still left, but imho we need them for sanity's sake, if we don't ever use the DB there's no point in opening the connection, and we don't know at any point whether or not the DB is actually still up if we don't open the connection and test in some way to see if WP is installed.

-the fact that there is compression for a cache file. To me, running a cache file through a compression algorithm of any sort is extra CPU cycles that you might as well have spent fetching the query over again.
-You die if a cache file can't be created, and ask for specific permissions (0777) on the cache directoy/files. Bad bad bad. Silently fail and work like normal, and we should not necessarily promote the use of insecure permissions on directories in any way in the core.
-Reliance on Apache to stop calls to the cache directory. Not everyone uses apache, believe it or not.
-In your implementation, select * from wp_posts would not be cached.
-PHP destroys objects and connections on shutdown, I see no purpose in doing it mid-request and/or needlessly doing it at the end

[foolswisdom]

Closing bug as WONTFIX for now as it has found no momentum on a month.