Tutorials for Magento and Joomla! - Yireo

Performance tuning with MageBridge

MageBridge makes it much easier to build a Joomla!-based e-commerce website, but with any good website performance is an important issue. This article tells you more about the performance issues of MageBridge and what you can do to improve the performance.

In short

• Place Joomla! and Magento on the same webserver (any server)
• Enable Magento caching (any server)
• Enable mod_deflate for both Joomla! as Magento (any server)
• Disable unused Magento modules (any server)
• Disable unused Joomla! extensions (any server)
• Use the right memory_limit in .htaccess (any server)
• Enable APC in Magento app/etc/local.xml (any server)
• Merge CSS and JavaScript files (any server)
• Add Magento hostname to /etc/hosts (dedicated server)
• Enable KeepAlives in Apache (dedicated server)
• Move Magento var/cache into tmpfs (dedicated server)

MySQL tuning

Performance with MageBridge relies heavily on a good performance of Magento. And because Magento makes intensive use of the MySQL database, tuning that MySQL database is vital. On any server (shared, virtual or dedicated) MySQL settings need to be modified, to make optimal use of memory. Settings include query_cache_size and innodb_buffer_pool_size. Ideally, you'll want to reserve half of your servers memory for the database (or more).

MageBridge caching

While MageBridge supports caching, implementing it is tricky and it requires a lot of work to bypass Magento for increased performance. MageBridge caching is documented here. While it is an important tool to increase performance, the best steps are to make Magento fast and furious first. If Magento runs slowly, trying to increase MageBridge performance is a waste of time.

MageBridge caching involves caching the Magento content-block (which is displayed in the MageBridge component) for various pages: Catalog-pages and CMS-pages can be cached, user-pages and/or checkout-pages can not. The game is to make less and less requests from Joomla! to Magento, so that Magento needs to initialize less objects. This can be reached through a combination of both MageBridge caching and Joomla! caching. The ultimate goal would be that for a certain page all the requests (product-page, category-module, tags-module) can be cached, so there's no reason for MageBridge to initialize the bridge anyway: All content (cached or not) is then served from Joomla! natively.

Optimizing HTTP and DNS

MageBridge integrates Magento within Joomla! by using a remote API. This allows for a clean solution without hacks in the code or hacks through the database, and also allows for more advanced configurations like webclusters and multiple Joomla! sites per Magento store. However, using this remote API involves extra HTTP-communication on each request being made, which takes more time and is bad for performance.

Optimizing HTTP is still another option: While you most certainly will not benefit that much by optimizing TCP-windows or datagram-sizes, one thing to pay attention to is DNS: It's best to add the Magento hostname to the /etc/hosts-file on the Joomla! webserver. This allows DNS to be skipped when MageBridge contacts Magento. If skipping DNS is not an option, make sure that the DNS-server is fast enough - both in resolving the Joomla! domainname as well as the Magento domainname.

Same webserver

Putting Magento and Joomla! on the same webserver will improve this a bit, because each HTTP-request only has to travel through the internal interfaces of the webserver and not over the Internet.

Magento caching

In general, caching is good. Magento is a complex application using a mix of XML and PHP to allow for very flexible configurations. But this complexity slows things down as well. That's why caching is a very smart thing to do. Within Magento Cache Management you can enable various types of cachable systems, and if things are cached on the Magento side, it means those things are fetched faster over the bridge.

Note that caching is good, but if you are storing your cache-files to a very slow disk, things might not improve that much. If the cache could be stored in memory, things would really speed up: You can either store the MAGENTO/var/cache folder on a memory-based filesystem, or modify the MAGENTO/app/etc/local.xml to use a PHP-accelerator for caching.

Joomla! caching

Be careful when enabling caching in Joomla! through the Global Configuration. Every module (including the MageBridge modules) needs to be inspected to make sure caching is only enabled, if that module does NOT contain any user-specific or session-specific data. Caching of the cart-module doesn't make sense.

Do not ever enable the Joomla! System - Cache plugin: It provides full page caching which is definitely not what you want.

Enable compression of webcontent

It is recommended to enable GZIP compression on both the webserver (Apache) as well as PHP. If both applications are configured to offer compression, the page might get compressed twice, but modern browsers do not reject this.

Within Apache the most common way to enable compression is by installing mod_gzip for Apache 1.x or mod_deflate for Apache 2.x. Within PHP you could turn on zlib.output_compression, but in general this is not recommended because other applications on the same webserver might object. Just make sure you have the zlib-extension compiled into PHP.

Disable unneeded Magento modules

Because MageBridge is depending on Magento, it should be clear that optimizing Magento also benefits the bridge. Disable all the modules you don't need (System > Configuration > Advanced > Advanced > Disable Modules Output). Note that this does not actually disable the module, but only the modules output. Alternatively you might want to disable the entire module-extension by editing its corresponding XML-file in the folder app/etc/modules. Of course, only modify this after you have made a proper backup.

Disable unneeded Joomla!/MageBridge module-instances

This is very important: When MageBridge is used on your Joomla! sites, for every MageBridge module-instance, theoretically a new Magento request would be needed to load the neccessary information. Because this would make your site deadslow, MageBridge uses the concept of pre-loading modules, to bundle numerous MageBridge requests into one big HTTP-chunk so that the Magento application is only called once.

So this means that Joomla! modules belonging to MageBridge, are preloaded. But this also means that you need to be careful when leaving modules enabled.  If you have a template which does not contain a module-position left, but a MageBridge Category Menu module is enabled and assigned to position left, that module will still be loaded and therefor slow down performance.

Use PHP accelerator

Make sure your PHP-environment supports APC, memcache, XCache, eAccelerator or some other kind of PHP-accelerator, because this will speed up things a lot. A PHP-accelerator will cache the compiled output of PHP-scripts, meaning that the PHP-parser will spend much time executing PHP-scripts. As a big plus side, all those PHP-files (and Magento has a lot of them) can be read entirely from memory, instead of a slow disk.

What is being loaded by MageBridge?

Enable the debugging bar in the MageBridge component, so that your Joomla! frontend is displaying details about which MageBridge elements are being loaded on a certain page. Note that the debugging bar requires your Joomla! template to have a messages-box. Within the debugging bar you will see an enumeration of MageBridge elements. Common elements like headers, breadcrumbs, meta and debug can not be removed. On MageBridge-pages the block content is also always loaded. But extra resources like blocks or API-resources could be tuned by disabling certain Joomla! modules and/or Joomla! plugins.

Enable or disable KeepAlive

When initializing HTTP-connections, there is the option to keep the connection alive for further requests. In general, this is good for a specific client, but if the webserver needs to deal with a lot of connections, this could cause a shortage of sockets. Per webserver, it needs to determined whether KeepAlive is a good thing or not. With MageBridge, KeepAlives are of importance for the client-Joomla! connection, the client-Magento connection and the Joomla!-Magento connection. You first need to make sure KeepAlives are enabled in the Apache configuration. For MageBridge, KeepAlives can be explicitely turned off in the MageBridge Configuration.

Disabling the MageBridge Content Plugin

The MageBridge Content Plugin allows Magento CMS-tags to be placed in Joomla! content, but for these CMS-tags to be dynamically translated into actual HTML-output, that Joomla! content needs to be sent to Magento. There's no caching here, so performance wise, it's best to keep this plugin turned off.

Replace ProtoType and Scriptaculous with Protoaculous or Protoculous

The ProtoType and Scriptaculous frameworks are used by Magento for many things, but for a hefty charge: To each page, an extra 220Kb is added. But the ProtoType and Scriptaculous libraries are not really optimized. Third party projects like Protoaculous and Protoculous (note the letter a as difference) allow you to downsize the JavaScript needed. The Protoaculous replacement works in almost all cases. The Protoculous replacement works in almost no cases and is therefor marked as experimental.

Use the Magento theme "magebridge"

Within Magento, the theme magebridge could be used to replace the original default theme. This magebridge theme contains various tricks to increase performance of your theme: Blocks like the header and footer (which are generally not needed in Joomla!) are removed. XML-layout code is optimized. The performance benefit might be small, but it's still a consideration.

Serve scripts through the Google API

If you choose to use ProtoType and Scriptaculous (and not one of their replacements), you can choose to load these JavaScript-libraries through the Google API. This saves you bandwidth of your own hosting environment, but adds ofcourse a dependancy on the Google webservers. 

Is JavaScript actually needed?

By default, if you configure the MageBridge Cart module on a certain Joomla! page, it will also be configured to load Magento JavaScript. But when the module is configured to display in Joomla! native mode, then neither Magento CSS or Magento JavaScript are required. Therefor, for every MageBridge module that is enabled, you need to determine whether JavaScript and/or CSS are actually needed for the module to function. In the end, this might prevent Magento JavaScript from being loaded on a lot of pages.

Only enable SSL for the checkout and customer pages

When using SSL every page needs to be encrypted by the webserver (Apache) and decrypted by the client (browser). This costs time. But with MageBridge/Joomla!, a lot of pages can be unsecure: Catalog-pages, blog-pages, etcetera. With Magento, enabling SSL for only specific pages is very hard and requires solid programming. With MageBridge, this is just a setting in the MageBridge Configuration.

Merge CSS and JavaScript in Magento

An average Magento site adds a lot of different CSS-files and JavaScript-files to the page, for which the browser needs to make extra HTTP-requests. Magento offers options to combine all CSS and JavaScript files into one single HTTP-request, saving bandwidth: Take a look at the Developer-section of the System Configuration.

Use memory_limit for Magento

Increase the memory limit for PHP-scripts by editing your .htaccess file:

php_value memory_limit 256M

Note that 256Mb is the bare minimum that Magento supports. Values from 512Mb up to 2Gb are common.

Disable unneeded Joomla! extensions

Disable all the components, modules and plugins that you don't need. Modules and plugins can be unpublished, but components can be disabled as well - navigate to the Installation Manager and then the Components-tab.

Use memory_limit for Joomla!

Increase the memory limit for PHP-scripts by editing your .htaccess file:

php_value memory_limit 64M

In many cases either 32Mb or 64Mb is sufficient.

Merge CSS and JavaScript in Joomla!

A Joomla! site might include many different CSS-files and JavaScript-files, for which the browser needs to make extra HTTP-requests. Use the Yireo ScriptMerge plugin to bundle JS and CSS for extra performance.