Joomla Mambo cache booster

Increase the performance of your website with the accelerate component 3.0 (!)

The Joomlatwork cache component is now also available for Mambo 4.6x, Joomla 1.0x series and the Joomla 1.5(!).

We are proud to release the new 3.0 release of the cache component. The cache component is now also available for Joomla 1.5 and Mambo 4.6.x. The 3.0 release is build from scratch again based on an own code base and libraries and is available for Mambo and Joomla websites Version 1.0b of the cache component is still available for Joomla 1.0x serie only or higher.

Standard out of the box Joomla and Mambo websites generates dynamicly webpages on the user request. This means that for each request the specific page must be composed by excecuting PHP code and SQL queries. On normal "hosting" environment the generation of a Joomla pages can take up to 0,4 - 1,4 seconds depending on the hosting environment and the number of components used. For large volume visitor sites this can result into slow performance of the website. When enabled this component can "generates" pages within 0,02 - 0,001 seconds (depending on your hosting environment)

If you want to boost your performance of your Joomla / Mambo website this component can help you. Before buying the component read the next coming paragraphs:

The component actual creates an cache environment around Joomla and Mambo. Please notice that this is a different caching mechanism that is default available within Joomla and Mambo: The default caching engine still needs to execute a lot of PHP code and SQL code and is therefore slow or will not function correctly.

How is this performance component working?

The basics of the caching engine is simple. When a page is requested by a user the cache components first checks if the specific page request is within the cache repository. If the page is present within the repository it checks if the cache is still valid, based on the time to live configuration parameter. If the page within the cache is vallid it is retrieved from the cache repository and sent to the user.
If the page is not present within the cache or if its no longer valid Joomla will generate the page. At the end of the page generation process the output of the request is written to the cache repository (if it's allowed by the filters which can be set within the cache configuration).

Please notice that this cache component is working with other core and third party component as long as these components doesn't alter the index.php file.

The caching mechanism will not work if a user logs in to your website. The cache is then disabled for the specific user until the user environment. If a users logs into the Joomla environment (frontend) the cache for the specific user is disabled until the users logs out. Actual you can configure the cache engine so that based on specific actions the cache can be disabled and you can enable the cache again also based on specific actions. For example the default config is when a user logs in (= POST action) the cache is disabled for the user until the user logs out (also an action)

The cache component functions almost like a static HTML page, although some php code must be executed to check and validate the cache. If a page is within the cache and is valid no SQL queries or an SQL connection is made. This means that your pages will shows even if your SQL database is not available (until the cache validation time is expired). This can save you a heavily load on your SQL backend environment for Joomla / Mambo

Before we have launched this component we have tested this component throughly within several websites. For example the component is now running on the KiKa website (http://www.kika.nl) and has drammaticly increased the performance of the website. With sometimes more then 3.000 visitors a day bad performance is no longer an issue. Standard page generation time was arround 0,5 - 5 seconds before the cache component was implemented and after the implementation the generation time is arround 0,02 - 0,004 seconds.

What are the "site" effects of the component?

When you apply the component at your website make sure that you are aware of the following:

If you are using 'dynamicly changing content parts' that change on each page request this will not work when you apply the cache component. For example when you display the date and time, the number of visitors online or dynamicly rotating banners will not displayed with the correct values. The reason for this is that the page is retrieved from the cache repository which represents the state when it was generate and stored within the cache repository. If the page is retrieved from the cache be aware that no interaction with the databases is made. If you have performance issues the only solution is to remove these dynamic displays or keep the time to live (= how long a cache page is valid) as low as possible. Also with the use of so called Ajax modules and components the content can be updated as will and the page will be retrieved from the cache.

Compatibility with SEF Patch extended version

The accelerate component is fully compatibel with the SEF Patch extended version. To make both components work first install the SEF Patch extended version and secondly the accelerate component.

Compatibility with templates and components using cookies

The cache component also support cookies within the URL cache repository unique key. For example Joomlafish is using a cookie to set the language for display at the end user. In this case the URL is the same but the difference in display is made by the cookie. In this case the cookie can be included with the URL to generate a cache page specific for the value of the cookie in combination with the URL. Also templates make use of cookies, for example the RocketTheme templates are using cookies for the display settings (larger fonts, etc...). If you have questions about these cookies please check or ask it in our forum.

Installation of the Joomla accelerate component

Installation of the component is simple. You can install the component through the Joomla installer, but make sure that the /index.php and the /administrator/index2.php files of your webserver has the permissions to be overwritten by the patch file (set the permission on 666) and make also sure that your root directory of your website (the location where the index.php is) and the root of the administrator directory is also writeable.
In the installation process the orginal index.php file in your webserver root is copied to jindex.php and the administrator/index2.php is copied to administrator/jindex2.php then the cache component will install the cache index.php file and the administrator/index2.php file. These files will included the original index.php file and the administrator/index2.php file.

If you get a permission error at installation time you can install the component simply by your self with a FTP program. Therefor perform the following steps:

1. rename your /index.php file into /jindex.php
2. copy the /administrator/components/com_jrecache/install_files/index.php to /index.php file
3. rename your /administrator/index2.php file /administrator/jindex2.php
4. copy the /administrator/components/com_jrecache/install_files/index2.php to /administrator/index2.php file

After installation you will need to "enable" the cache through the configuration panel. When you enable the cache make sure that the 'default' settings are correct. For example the component uses the default location of your website configuration file, but if this is located on a different location due to security reasons correct the path in the configuration setting.

ithin the Administration panel you can administrate the behauviour of the cache repository.

Configuration settings:

Within the component you can set the following configuration parameters:

Configuration parameter	Description / usage
Host configuration file location:	The location of your Joomla or Mambo configuration file setting. The component will assign the default configuration location. Make sure that this is the correct setting.
Enable cache:	With this paranmeter you can enable / disable the cache function. Default value when you install the component is disabled since you must assign the cache directory for the cache repository.
Cache directory:	The location of where the cache files should be stored. Default is this the joomla cache directory located within the root of your webserver. Make sure that your cache directory is writable! Make sure that you have enough free disk space available (depends on the number of pages and the size of the pages within your site)
Cache time to live:	The time that a cached page is vallid within the cache repository in seconds. Default value is 3600 seconds and depends on the number of changes / updates on your site. This parameter is applied when a specific page is created and stored within the cache repository. If the cache time to live is expired the cache is generated on the first request when it was invallid.
Enable automatic garbage collection	Enables the automatic garbage collection. If enable the cache will be cleaned up periodicly according to the time settings of the garbage collection. Notice that this function will only removed outdated cache files from the disk.
Garbage collection time schedule	Number of seconds that the automatic garbage collection should be initiated (if enabled). Garbage collection will remove outdated cache files from the cache folder. It's initiated on the first page request when the time periode is expired and when a cache page is created.
Enable compressed cache storage:	This parameter allows you to store compressed (zipped) pages within the cache repository (recommended). This reduce the needed diskspace for the cache with around 70-80%. Default setting is on. Note: make sure your website supports zip within PHP.
Use GZIP output page Compression:	When enabled this parameter will sent the cached content zipped to the requested browser if the client/browser supports gzip encoding (almost all browser support gzip encoding). If the client / browser doesn't support gzip encoding the cache page will be sent normal to the requested client. Notice that when you have a high visitors rate this could save you bandwith at your hosting provider (about 70-80% in relation to no zipped content)
Enable POSTS to be cached:	Default posts are disabled from caching. In this case you can prevent that form submissions are cached. This is done for example if you a user submits a form whereby the output of the form is customized in regards of the form submit (for example error pages based on form submissions).
Enable debug:	You can enable the debug function for the cache component. When enabled the debug information is written to a log file.
IP -address for debug:	If you enable the debug functionality you will need to enter the ip-address which can view the debug information. In this case only the specific ip-address can view the debug output. Default the ip-address will be stored of your connection when you edit the configuration for the first time. Otherwise make the this field empty, save the configuration and reenter the configuration setting. The ip-address contains the value of your current connection. You can also put a * into this field meaning that all page requests will be stored within the debug file.
Location debug file:	The location of the debug file. Default the debug file will be stored within the cache directory. Make sure that the debug file is writeable. If used in the cache folder you can view the debug logfile through your web-browser by: [yoursite.com]/cache/jrecache_debug_info.out
Drop http hack try requests:	The 2.0 cache component release has the ability to drop so called hack requests to your website if the requests is made through the main index.php. Many hack requests for Joomla and Mambo are performed with an URL referrer in the URL request to your site. Each URL referrer request can be dropped when this option is enabled. Example the URL request will be dropped with the following request since this is a hack effort: /products/free_products_for_joomla/?mosConfig_absolute_path=http://www.xxxx.com/shop/data/id.txt?
Cookies to support	Several templates make use of cookies to display the content on different way. For examle to change the width of the screen or to change the font size or font color dynamicly. This is based on cookies. To support a correct cache representation the cookie should be part of the unique hash for the cache. In this case the cached page is based on the URL + cookie name. You can add multiple cookies by separating the value with a "\|" sign. This also works on Joomfish which uses cookies for the display of the correct language within the frontend. Known cookies: Joomfish: mbfcookie[lang] Template based cookies: Rockettheme: c-colorstyle c-fontstyle c-widthstyle (notice that rocket theme sometimes uses other cookie names) The best way to check which cookies are used is to use the firefox browser with the cookie viewer extension installed. With the extension you can simple click on the right mouse button, select page info link and then select the tab cookie info. Check this particular for the template based cookies.
Disable cache if the following cookies are used:	You can disable the cache if certain cookies are used by adding the cookie name (no value!) in this field. See above how you can get the cookie names with the firefox browser.
Set the bypass cache cookie if the following actions are set:	This setting is used the disable the cache for a specific visitor when a specific action takes place. Default this field contains the setting that the cache should be disabled when a user logs in to your frontend website. If this happens the cache engine will set a cookie that will by pass the cached pages and the pages will be created dynamicly for the logged in user.
Clean the bypass cache cookie for the following actions:	This setting is used to enable the cache again for a specific user when a specific action takes place and the cache is disabled for the specific user. For example when a users logs out of your website the cache must be enabled again for the user. Default this field contains the logout option setting.
Enter URL parts that may not be cached:	Within this field you can enter part of URL's that may not be included within the cache, each line is a new "url" filter. For example if you don't like that a specific component is not cached entier the part of the URL in this field and URL's that apply to this part will not be included within the cache and always bypassed by the cache engine
Disable for cache if the page content contains	You can disable certain pages from the cache if the content of the pages contains specific "content". Standard this field contains the "Pages not found / 404" values of the Joomla language files. This is because the page not found pages should not be included within the cached pages. By adding the text within this field you can prevent that these pages are stored within the cache. To make this simple: just edited your Joomla language file and find the text for the page not found error. Just add a simple code into this message and apply this into this content filter. (avaible from release 1.0b, 20 april 2007)
Enable automatic cache deletion for Joomla backend	When enabled the cache will automaticly be cleared if specific actions in the backend are executed. For example it's possible to clear the cache when a Joomla content item is saved. In this way the frontend (your website) is always up-to-date with the latest changes. If you make only adjustment to the content with the Joomla backend administration you can set the cache TTL to 0 (means that the cache wil live for ever) and that the cache will be cleared automaticly when updates are maded Notice: the automatic cache deletion is default disabled. (avaible from release 1.0b, 20 april 2007)
Removes the cache if the following joomla admin actions are performed	In this field you can apply the parameters / actions on which the cache must be cleared when a specific Joomla backend action is performed. The Joomla framework is based on the following parameter structure: option=[joomla option] and task=[joomla task] Each line represents a Joomla action which can exists from multiple parameters and to clear the cache each action on the line must be "vallid". Seperated the parameters with the "\|" sign. Examples are: option=com_content\|task=save option=com_content\|task =remove In this example if the above "rule" is met the cache will be deleted when a content item is saved and the other "rule" will clear the cache when a content item is removed. With the installation of the component the most common Joomla backend action are default present in this field. (avaible from release 1.0b, 20 april 2007)
Enable the automatic cache deletion for the frontend	The same kind of parameter as the backend admin. When enabled the cache will automaticly be cleared if specific actions in the frontend (public website) are executed. For example the cache can be cleared automaticly if someone posts an entry in the guestbook of your website.
Removes the cache if the following joomla frontend actions are performed	Same as the Removes the cache if the following joomla admin actions are performed field. (avaible from release 1.0b, 20 april 2007)

Cleaning up the cache repository

You can clean up the cache repository through the administration panel->Clean up the Cache repository. When you select this option you can choose "to delete all files within the cache repository" and "delete the outdated and invallid cache files" within the cache repository. With the first option all the files and the records within the SQL database are removed either the cache entry is vallid or not. The second option only deletes cache entries that are no longer vallid (e.q. purpose is to make diskspace available from cache files that are no longer used).

From version 1.0b and later it's also possible to cleanup the cache when specific actions are performed. Within the configuration you can apply "rules" for the backend and for the frontend if specific actions are performed.
For example for the backend: if a Joomla content item is saved, deleted or published the cache can be cleared automaticly so that the frontend is always up-to-date. When you apply this rule you can set the TTL of the cache to 0 since every updated in the backend (or frontend) will clear the cache automaticly (if the rule is defined in the cache config).

Overview of the cache repository

Within this option you can get an overview of the records that are stored within the cache repository. Each file that is located within the cache repository is stored within a SQL table which enables you to manage specific pages within your cache repository.

Within this view you can add a new "cache" entry and don't allow the specific URL to be cached.

You can also edited an existing URL / cache entry and disables the caching for this spefic URL.

You can also remove a specific URL from the cache repository if needed.

Notice: disabled URL's are not removed when you clean up the cache repository within the administration pannel.

Reinstall the index.php file

When the first installation was not succesfull you can reinstall the needed index.php with this option. This is ussualy the case if the index.php could not be replaced at the installation time of the component.

Restore the original index.php file

At installation time a backup of the orginal index.php file is made. With this option you can restore the "orginal" index.php when needed.

Deinstallation of the component.

When you deinstall the component the orginal files are restored.

< Prev		Next >