ExSite ships out of the box to run in a basic CGI mode. This is to ensure maximum portability, as it will install in this configuration on a wide variety of server setups. However, for high-traffic web sites, there are numerous performance-enhancing steps you can take to make ExSite run much faster.
The ExSite Store is a high-speed persistent data store that allows data to be shared between different processes. It is much faster than going to the database to pull up data, so it will improve performance on frequent queries. The ExSite::DB library will automatically make use of the Store as a database cache, if it is enabled. The store will also be used to cache system configuration, so it does not have to be reloaded on each request.
There are two types of storage engine that the store can be built on: DBM and SHM. DBM engines use a disk-based hash file to hold persistent data. SHM engines uses a shared memory segment instead. You can also run in a dummy-store mode that uses no storage engine; this effectively means that your store is not persistent. ExSite will automatically fall back to this mode if it cannot establish one of the other two store types.
SHM uses memory, and DBM uses disk for storage. That should mean that SHM is faster, but in practice DBM benefits from filesystem caching and they are comparable in many cases.
SHM is a little easier to set up, since the shared memory segment should be created automatically for you.
If you run multiple installs of ExSite on a single server, using DBM will will keep the data stores physically separated. (With SHM, all sites will try to use the same store; while the store will try to keep the data separated, there may be security/privacy issues with a shared store. Also, the store stats will reflect combined usage from all sites.)
Items stored in DBM will persist even through a server reboot, which means sessions and other persistent data will still be active when the server comes up again.
If you are memory-bound, DBM will use less memory, especially if the data store grows unexpectedly large.
ExSite automatically tries to establish a connection to a DBM store, and if that fails, to an SHM store.
The DBM store needs to be initialized manually. If you have not done this configuration, then ExSite will not succeed in connecting to it, and will setup an SHM store instead. (No manual initialization is required for SHM, so it should self-configure automatically if your OS supports SysV IPC.) That effectively means that SHM stores are the default, with DBM available as an alternative.
To force the use of DBM over SHM, execute the following shell commands in your CGI-BIN directory to initialize the DBM store:
% perl -e 'dbmopen(%s,"STORE",0666)' % touch STORE.lock % chmod 666 STORE*
Comment out the first line of ExSite::Config::exsite_init() to disable the persistent store entirely.
Other than selecting the appropriate engine for your system, there are a few tuning parameters hard-coded into ExSite::Store which you can use to adjust how the store works:
max_size: [default 10000] This is the maximum size, in bytes, of an item that can be placed into the store. Setting it larger will allow you to cache more items, including many files or content revisions that would otherwise exceed the default limit. The penalty you pay is that the store will consume more resources (memory or disk, depending on the engine). Setting it lower will reduce the number of items you cache, but leave more resources available for other server processes.
max_lifetime: [default 1440 minutes = 1 day] This is the maximum amount of time that an item can survive in the store before being automatically removed and forcing a reload. Increasing it will cause fewer reloads, although once-daily reloads should not be a big deal unless the operation is very costly. Decreasing it will cause more reloads, which may negatively impact performance.
max_idle: [default 60 minutes = 1 hour] This is the maximum amount of time that is allowed to transpire between requests of an item in the store. If an item sits in the store for longer than this without being requested, it will be removed to conserve resources. Increasing this will make items more persistent, which will have a minor performance benefit if they are accessed semi-regularly throughout the day. Decreasing this will make items less persistent, but will also make the store consume fewer resources.
Using internal methods in the data store, you can also modify max_lifetime and max_idle for individual items, so that they will expire under different terms than other items in the store. Setting either to -1 means the item will not expire due to overall lifetime or idle time, respectively.
Persistent Perl (aka SpeedyCGI) is very easy to implement under ExSite. Simply install the PersistentPerl/SpeedyCGI packages on your server, and replace the shebang line on critical scripts with the appropriate replacement interpreter, eg:
#!/usr/bin/speedy
If you have multiple installs of ExSite running on the same server, you will need to split them into execution groups so that you don't end up running page.cgi from the wrong website:
#!/usr/bin/speedy -gTHIS_SITE
If you find that the programs or plug-ins have memory leaks and grow unreasonably large over time, you can specify after how many executions the program should restart fresh.
#!/usr/bin/speedy -r100
You have the option of doing this on any or all of the ExSite CGI programs. For increased website visitor performance, the following scripts can be sped-up:
content.cgi dcd.cgi page.cgi
For increased performance on adminstrator tools, the following scripts can be sped-up:
ctrl-panel.cgi home.cgi dlg_*.cgi
The cgi tool for debugging and performance profiling does not work with persistent perl. For this reason, you will have to restore the shebang line to #!/usr/bin/perl to do debugging or profiling work on the code. As a general rule, it is easier to use basic perl in a development environment, and switch to persistent perl in a stable production environment.