Cache the datastore in the filesystem

Ok, the purpose of this hack is to move the huge parts of the datastore,that are called each time you access a page, into a file unserialized and passed through var_export in order to save the time used to load the data from the database and to unserialize it. If you're using a PHP optimizer, like eAccelerator for example, this may save even more time I think. The result is, that huge arrays, like the forumcache are now loaded simply by executing

PHP Code:

require_once(DATASTORE_FILE_DIR.'datastore_cache.php'); 


in your init.php.

Additionally this saves 4 calls to the function unserialize, which is broken in PHP 5.0.3 and 4.3.10, so this should be a good work around until PHP 5.0.4 and/or PHP 4.3.11 has been released.

It tries to finish, what has been started in the code and AFAICS you can even find the beginnings of that in the init.php of vB3.0.6,although I'm still running vB 3.0.3, so I can't tell, that this works without problems in newer versions.

Some Notes:

• I recommend to place rebuild_dscache.php into a protected directory and to alter the first chdir(...); in the script, so that no one can abuse this, by flooding your forum with calls to that script.
• Additionally you should remove the backup-files named datastore_cache_TIMESTAMP.php in your includes dir (or wherever the datastore-cache is stored) from time to from to save disc-space.
• Use this at your own risk and make sure to backup first before installing this hack.
• This hack is not designed for a multi-webserver setup. So unless the data on the filesystem is being updated on the fly its not recommended to install this.

Changelog:
0.8.1 Alpha:

• removed a relic of an old hack from dscache.txt
• Added config_dscache.php
• backups can be turned off now
• you can change the directory, where the datastore_cache.php is stored now
• Fixed a bug, that may cause unserialize-errors in the CP out of the blue
• rebuild_dscache.php is verbosive now

0.8.2 Alpha:

• Added CVS-Ids to some files
• Added a note to rebuild_dscache.php
• Added a note about PHP < 4.2.0 to dscache.txt

0.8.3 Alpha:

• Removed some relics of the old backup functionality
• some changes to make it possible to run it at the commandline (see below)
• Allow to specify a key in the config-file, so this script will only run if you specify the correct key (-k KEY on the commandline or ?key=KEY in the URL)
• You can make the script silent by adding -s respectively ?silent=1

1.0 (Final):

• No changes at all. All files are the same as in Version 0.8.3 Alpha.

[Erwin]

Very very very cool. I must try this.

[Andreas]

Hehe, I did that a few days ago
But I think there as not much difference in perfomace, once the bug in unserialize() has been fixed.
IIRC can can find discussions about this on vB.com, whre one of the Devs said that this is even slower then using the DB.

[Erwin]

That was what my concern was. But while php 4.3.10 has that serialize bug which does slow my site down, this is a nice workaround.

[kall]

From the guy who runs my host:

Originally Posted by ASO

We've been fine and the actual places where unserialize are used in vB are relatively minimal compared to other areas of script execution. Believe me, it does not have as much of an impact as you may happen to think. And we'll upgrade as soon as a stable version is released (which I imagine would be soon).

Is he correct? Is it 'relatively minimal'?

(I tried this hack but it blew up in my face with foreach errors and stuff...I have apostrophes in my forum descriptions and it caused errors in functions_datastorecache.php ... )

[Stadler]

Originally Posted by kall

From the guy who runs my host:

Is he correct? Is it 'relatively minimal'?

(I tried this hack but it blew up in my face with foreach errors and stuff...I have apostrophes in my forum descriptions and it caused errors in functions_datastorecache.php ... )

The impact is relative to the amount of forums and usergroups you have, since this could bloat up your forumcache. And I can't confirm your problems. We have forums with apostrpohes in the descriptions, too.

IIRC can can find discussions about this on vB.com, whre one of the Devs said that this is even slower then using the DB.

mmh, then it's the connection between the webserver and the database, that slows down our forum, since I've recognized a difference of about 0.5s, after activating that hack. Our forum runs on a version of PHP, thats rather old, that is ...

i'd like to see a performance ranking on this hack, hit to a db like the one here on vb.org ...

[Acido]

I cant found this code in includes/init.php

PHP Code:

 $optionsfound = !empty($vboptions); 


Can you provide another location to add the hack code?

I'm using vbulletin 3.0.1

Thanx in advance.

[Erwin]

Mmm... you need to chmod 0777 the includes directory or you get a permission denied. Correct?

[Erwin]

Okay, got it working 100% with my other hacks. Thanks!!! This has helped my multi-server setup. Will wait till we are at peak times and compare...