Board Optimization - Dynamically Linked Source - Speed Up Your Multiple Site Network & Upgrades

For the purposes of this documentation, "Network" refers to a group of forums on a single server or cluster of servers.

When 3.7.1 PL2 was released, I posted over at vbulletin.com lamenting the fact that I had 15 upgrades to perform and how it would be nice to have a multiple site license to lighten the burden of downloading each install separately. In the end, I spent much more time coming up with this system.

Dynamically Linked Source or DLS allows operators of two or more forums on the same server or cluster, for all intents and purposes, to use one set of source code instead of multiple sets. By using one set of source code, Op code caching is much more efficient as only one copy of the source is cached. This greatly reduces the amount of memory used caching the source code, and also makes it more efficient. It will lead to less fragmentation for systems using APC, XCache, eAccelerator, or other such methods of caching Op code.

The method uses symbolic links to a central repository of the source code. Therefore, upgrades to all sites on the network can be done quickly by just replacing the source. For patch level releases, this means the entire network can be patched with one upload. Upgrades to a new version can be done this way, or a new repository can be created and each site can be upgraded one at a time.

The issue of licensing has also been addressed. Once the product file is installed, and assuming the installation instructions were followed, each installation will report the proper license key when salting cookies, or reporting back to Jelsoft as Vbulletin does from time to time (mostly in the AdminCP).

I contacted the development team at Jelsoft and discussed this method before releasing it, and got the OK from Mike. I was initially concerned that it may break licensing or perhaps give away too much of the license reporting methodology, but now that I look back, it really does not do either.

In tests on a rather large network that contains seven forums with about 7 million posts, hundreds of thousands of registered users, and uses three load balanced servers the load has been reduced by almost 40%. You can see in the graph attached to this thread for the particulars.

I have tried to make the readme as clear as possible, but honestly that was never one of my strong points. I cannot emphasize more that before you implement this method, TEST it first in your sandbox. Also, make sure you backup your software and database before you use this.

I also have included a PDF that explains what is happening in greater detail.

Updates:

8/20/08 - This will work with the latest version of VBSEO (3.2.0 at this time). Add all the files to the DLS except the config file, and run the php-clone.php script.

This product was developed for Andy R from Social Knowledge and released here for others to enjoy.


Please don't forget to click install as I have worked quite a while on this.

[sockwater]

I just tested with junctions as well. Apache reads them just fine. Use this command, after downloading junction.exe from Microsoft.

junction -s newvbdir oldvbdir

newvbdir will now be a symlink to oldvbdir, including all files and directories recursively. It seems to work the same way as a hard link, if you change the contents of either file it changes the other.

The bottom line is both junctions and hard links should be tested to see if the opcode caching only caches one copy of the file or multiple copies.

[Jafo232]

Don't forget what you have to do with the config files.

[y2ksw]

Originally Posted by sockwater

I just tested with junctions as well. Apache reads them just fine. Use this command, after downloading junction.exe from Microsoft.

junction -s newvbdir oldvbdir

newvbdir will now be a symlink to oldvbdir, including all files and directories recursively. It seems to work the same way as a hard link, if you change the contents of either file it changes the other.

The bottom line is both junctions and hard links should be tested to see if the opcode caching only caches one copy of the file or multiple copies.

I tried this first. It seems as if the cache sees just one copy, thus theorically it would work. Practically however you can't use it for vBulletin because of the configuration file which can't be separated with junctions. junctions would make sense though if you had your board files in a different disk or folder - which may become handy when moving a site.

Now I'll try the fsutil solution.

[Jafo232]

Originally Posted by y2ksw

I tried this first. It seems as if the cache sees just one copy, thus theorically it would work. Practically however you can't use it for vBulletin because of the configuration file which can't be separated with junctions. junctions would make sense though if you had your board files in a different disk or folder - which may become handy when moving a site.

Now I'll try the fsutil solution.

Well, you probably can if you follow the directions in this mod. You have to create a configs folder in the includes directory. Place your site configs in there and rename them uniquely. Then use the config file in this mod.

[y2ksw]

I've tried now both systems (junction, fsutil) on a clean test environment. Both systems are not cached once, but as if they were separate files. A clean 3.7.0 installation and copy produce each about 2.55 MB of uncompressed eAccelerator cached files on forum home (index.php).

• The junction feature requires to rename the config.php files and is a one-liner.
• The fsutil feature replaces the single files with a hardlink to the common files folder, and allows thus to keep some of the files in their original state. Thus, renaming of config.php and other files are not necessary. fsutil requires an utility to execute recursively. Please allow me to test it a little before releasing
• Both features require to repeat the junction/fsutil calls on each copy. It is not possible to copy and paste those links, and doing so, will just retrieve the original files.

[Jafo232]

Well, if they are not caching in your windows environment, I don't see much of a point other than speedier upgrades. Getting Linux of course would solve all of this for you. (Couldn't resist)...

[UaECasher]

This mod is great

[y2ksw]

This utility automates the use if fsutil on Windows Servers. It has been tested on XP Pro and Windows Server 2003, and comes with the full source for Visual Basic 6.0.

Please try it first on a test environment and make a backup before linking the files.

I will not assume any responsibility for your test and/or production environment! Use on your own risk.

[sockwater]

Originally Posted by y2ksw

I've tried now both systems (junction, fsutil) on a clean test environment. Both systems are not cached once, but as if they were separate files. A clean 3.7.0 installation and copy produce each about 2.55 MB of uncompressed eAccelerator cached files on forum home (index.php).

• The junction feature requires to rename the config.php files and is a one-liner.
• The fsutil feature replaces the single files with a hardlink to the common files folder, and allows thus to keep some of the files in their original state. Thus, renaming of config.php and other files are not necessary. fsutil requires an utility to execute recursively. Please allow me to test it a little before releasing
• Both features require to repeat the junction/fsutil calls on each copy. It is not possible to copy and paste those links, and doing so, will just retrieve the original files.

I wonder if APC handles junctions/hardlinks on Windows the same way eAccelerator seems to-- seeing the files as the same or different files. On the other hand, maybe this could be a feature request for eAccelerator/APC, maybe something can be tweaked in their code to make them recognize that hardlinks and junctions actually refer to the same file.

[thompson]

very interesting. will try it.