After installing the dmc_highPerformance extension in the extension manager, you have to configure and activate the various optimization aspects. Without any aspects configured and activated the extension will only improve TYPO3s SQL-statements so that the MySQL QueryCache works more efficiently.
In the extension directory, locate the configuration file conf/config.php and open it to start with configuration.
The activation of the PEAR::Cache within this extension indirectly takes the MySQL QueryCache to a new level. The extension uses the PEAR::Cache module to cache SQL-resultsets in local files. So when the same set of data is requested again, the result can be taken from the cache on the local webserver and the database server is not queried at all.
In high traffic environments it is a very common setup to have not one webserver but a whole cluster of them. The database server is much more difficult to cluster. So a setup with several webservers but a single database server is very common.
Now, performing a query on an idle database server is about as fast as requesting a single cache file from PEAR::Cache. So essentially, if your database server has not hit its limit you probably won't see an increase in performance by activating this feature.
But if the sheer amount of requests is beginning to slow down the MySQL server, the same simple request requires more and more time, hence the delivery of HTML slows down.
In a multi-webserver, single-database setup under heavy load you can activate the PEAR::Cache feature of this extension. What happens is that the results of the highly frequented SQL-statements are essentially clustered among every webserver. The database server does not have to work on these statements anymore and can use its CPU-power to other requests. So while a single cache-request with PEAR does not outperform a single SQL-statement in MySQL, they can be distributed among many machines.
The dmc_highPerformance extension enables you to cache almost every highly frequented SQL-statement from TYPO3. The exact figures on your system will vary greatly with the extensions installed, the exact content of your pages, any many other things.
Note that when you're using networking filesystems to share some or all scripts within DOCUMENT_ROOT, do not set the directory where PEAR::Cache stores the cache files to the network system! Although at first it seems tempting – the cache has to be generated only once, on a single machine and is instantly available on every machine – those filesystems tend to be way too slow for this purpose. Local filesystems are a much better option, even if this causes the cache to be redundant on every webserver.
The dmc_highPerformance extension enables you to use PEAR caches even for TYPO3 pages which are for some reason uncacheable by TYPO3. See the T3PEAR_CACHE_UNCACHED_PAGES constant in the config.php file.
On highly dynamic pages, we did experience the situation that certain elements on a page can not be cached by TYPO3, for example because the content changes several times per day at unpredictable intervals. Our solution to this is the setting mentioned above – we cache the SQL-statements with a time-to-live of 10 minutes (the default). That way we again do take a lot of load off the database, but keep things flexible enough to update the HTML when preconditions change.
Whether this feature is for you will greatly depend on what you do with your TYPO3.
Whenever you click the “Clear FE cache” button in the TYPO3 backend, the dmc_highPerformance extension will make sure that the PEAR::Cache files will be removed as well. A Linux shellscript is used in conjunction with the wget commandline tool to propagate the “flush” command to all webservers of your cluster.
However to be able to do that it must be possible for every webserver of the cluster to call every other webserver via HTTP. Please see the configuration section of this manual how to set up the extension in a multi-webserver environment.
This feature is only interesting to you if you've set up your production database servers in a way where you have one active “master” server which receives and answers all requests, paired with one or more passive “slave” database servers which permanently sync their database content with the master server to act as a drop-in backup in case the master fails.
MySQL provides a binary log (the “binlog”) which is generated by the master database server and which contains every single SQL-statement that alters the database layout or its content. The slave database servers are configured to connect to the master and continuously read the binlog from the master to apply the changes to the database to their own copy to keep it up to date.
Unfortunately it is not possible to configure the MySQL binlog replication in such a way where some tables are not included in the replication process. In a TYPO3 environment those tables that are used to store the HTML caches really do not have to be replicated since they contain only data that can be re-created any time.
What MySQL provides is a way to switch the binlog replication on and off within a SQL connection. The requirement for that is that the MySQL user that TYPO3 uses possesses “SUPER” privileges in MySQL. If that is the case and your database servers harddisks are becoming a bottleneck because of the generation of the binlog, you can set the MYSQL_BINLOG_SPEEDUP constant to true and activate the speedup.
What the extension will do is to deactivate the binlog before a HTML cache is altered and reactivate it directly afterwards. Additionally the same will be done with frontend user sessions. So if your website is using the fe_session to store important data, this setting is not really an option for you!
The one aspect that you cannot configure is the fact that the dmc_highPerformance extension changes the way in which TYPO3 generates SQL-statements. Many times, TYPO3 uses a timestamp to indicate certain events like something going online or offline (a page, pageelement, TS-script, ...). By using a timestamp TYPO3 is essentially creating a different SQL-statement every single second for many elements it queries.
The MySQL QueryCache is an in-memory solution for caching results that are requested frequently. The goal is to provide the resultset faster and to keep the harddisks free to gather the data for other, uncached requests. Since TYPO3s usage of timestamps, there really are no SQL-statements that are requested frequently: The statements change every second since the timestamp changes. This essentially renderes the MySQL QueryCache useless and slows down the database.
The dmc_highPerformance extension uses a method highPerformance::roundTime() to round those timestamps to ten-minute intervals. This way, the SQL-statements that TYPO3 generates change only every ten minutes, an improvement by 600 percent.
The one disadvantage is that the online / offline settings of TYPO3 are no longer precise to the second. However we strongly believe that a ten minute interval is a good compromise between speed and the efficiency of the MySQL QueryCache on one side and TYPO3 precision on the other.
I activated the PEAR::Cache feature. How can I see that the extension is actually improving my performance?
There are two operating figures which will tell you that the extension is actually doing its job:
First of all, the “Total parsetime” and “Parse template” figures that are displayed in the TYPO3 admin panel in the frontend should decrease when caching is active and this page has been cached already.
Second, the number of queries per second that the database is hit with will decrease over time.
I installed the extension and the frontend dies with a FATAL error telling me that Cache.php cannot be found?
Your PEAR basepath is not in your PHP include_path directive (set in the php.ini). Either add the path to the include_path directive or change the require_once() statement in the conf/config.php file of the dmc_highPerformance extension.
After flushing the frontend caches I still see PEAR::Cache files on some webservers!
The shellscript of the dmc_highPerformance extension is not able to propagate the “flush cache” command to all webservers. See the configuration section on how to do that.