Tutorials for Magento and Joomla! - Yireo

Benchmarking MageBridge performance

So now and then, it is claimed that MageBridge is slow. It combines Joomla! and Magento into one webapplication, so it must be slower than Magento standalone. In many cases, these conclusions are based on personal feelings and not solid facts. This whitepaper tells you how to gather the facts, and get a clear view on what is causing what to perform how.

What to benchmark?

When benchmarking MageBridge, you have to bear in mind that MageBridge offers a lot of functionality, and therefor analysing its performance is a complicated task. To do a proper benchmarking, you therefor need to pay attention to the circumstances under which the benchmark was made. This whitepaper will start with some considerations that you need to keep in mind, when measuring performance.

Consideration: Total pageloads or just application-time?

When a webpage is loaded, applications like Joomla! and Magento will generate HTML-code that is displayed in the browser. But besides the HTML-document, many more resources might be loaded as well (CSS-stylesheets, JavaScript-files, images). Depending on your configuration, MageBridge might load more CSS-stylesheets than Magento standalone - the Joomla! template and the Magento theme might both be used. This causes a MageBridge page to be slower than a Magento page. But, on the other hand, Magento loads the full-blown ProtoType / Scriptaculous library (over 300Kb in size) but MageBridge might load the Protoaculous library (just 170Kb in size) - which would make a MageBridge page faster again.

Measuring the full page with all its resources, requires you to take in the fact that all these CSS-stylesheets and JavaScript-files are fully customizable. Performance optimization is a very good thing here, but making performance benchmarks makes a lot less sense. 

Instead, you could also just measure the speed at which the HTML-document is loaded. This leaves out JavaScript and CSS, and only focuses on the application-time. In this whitepaper this is assumed: Benchmarking of the actual application-time - regardless of the extra resources needed to display the page.

Consideration: MageBridge initialization versus Magento initialization

With MageBridge, both Joomla! as Magento are combined in one page. The simple conclusion might be that MageBridge is slower. This is too easy. When the Magento application is initialized in a normal Magento environment, it does so by fully initializing the XML Layout with all its blocks (Mage::run()). When MageBridge is used, only part of the Magento application is initialized (Mage::app()). A lot of times, this means that Magento is initialized in 70% of the time that Magento would otherwise require.

This sounds awsome, but - while MageBridge is fast in calling upon Magento - time is wasted due networking connections and Joomla! initialization. In the end, our experience is that MageBridge (with Joomla! and Magento initialization taken in) could be as fast or faster than Magento standalone - depending on how many Magento blocks are displayed within Joomla!. In many cases, the difference between both solutions is measured in tenth-of-seconds (for example: 3/10 seconds faster or slower).

Consideration: Magento caching

Magento performance is bad when Magento caching is disabled. So a lot of benchmarks are made when Magento caching is enabled. However, when using Magento caching, it is very important to realize that there is a huge speed-difference when Magento needs to (re)initialize the Magento cache (because it needs to be refreshed, or is still empty after cleaning the cache), and when Magento is able to use an already initialized Magento cache.

In more simple words: When you enable Magento caching, and you visit a product-page for the first time, it will take extra time to build up the Magento cache for that time. But afterwards, if you refresh the Magento cache, the same product-page might load multiple times faster. The Magento cache itself might be lightning fast (cache-read) but the initialization of the Magento cache might be terribly slow (cache-write).

Consideration: Minimizing Joomla! application

When measuring performance of MageBridge, it's best to keep the Joomla! application to a minimum while measuring. Loading too many Joomla! plugins might cause the total pagespeed to slow down. Also, extra Joomla! modules could require extra resources as well.

You could decide to load the entire page by just calling the URLs that you normally would. You might also strip out the Joomla! template and Joomla! modules, as to only measure the performance of the MageBridge component. For this you could add the URL-parameter tmpl=component to the URL.

http://JOOMLA/shop/catalog/product/view/id/292?tmpl=component

Enable MageBridge profiling

Within the MageBridge configuration, you can enable debugging, and once you do this, profiling messages will be gathered by MageBridge. If you want to debug only one IP-address, that IP-address can be entered, or you can debug all IP-addresses by keeping Debug IP empty. Set the Debug level to Profiler. It's easiest to log debug-messages to the Database. Also remember to set the Debug bar to No, otherwise all your visitors will see the debug-bar on your site.

After these settings, you can visit the frontend. Messages will be logged to the database and are visible by navigating within your Joomla! Administrator to the MageBridge Logs. Note that refreshing a frontend-page only a couple of times, already gives a very clear view on what is happening with performance.

How MageBridge loads a page (Joomla! part)

When MageBridge is used to serve a page to a visitor, the visitor (browser) will request a certain URL and that URL will be served by the Joomla! application. After the Joomla! application has started, it will spend some time on Joomla! plugins being loaded, after which the component is being called - which is, in the case of MageBridge-pages, the MageBridge component (com_magebridge).

The MageBridge component will open up a HTTP-connection using CURL and send the HTTP-request through CURL to Magento. With MageBridge debugging, the time to initialize CURL and send the request, will be logged as CURL connect time. If this is slow, it might be due to slow DNS-lookups or server-settings that cut down download-speeds. To optimize this CURL connect time, the hosting server needs to be modified.

After this, Joomla! will wait for the HTTP-response from Magento. The total time that Joomla! needs to wait before getting back the HTTP-response from Magento, is logged under CURL total time. By extracting the CURL connect time from this, you can know how long the actual Magento application to generate output - which should match (more-or-less) the application-time reported by Magento (see below) - give or take a few 1/10 seconds.

How MageBridge loads a page (Magento part)

Once the Joomla! application has sent a request to Magento, Magento will pick up on this request. Usually the Magento-file index.php is used to startup Magento, but with MageBridge the file magebridge.php is used instead. The first task here is to initialize the Magento application through the system-call Mage::app(). This is logged as such within the MageBridge logs. When this takes a long time, this has nothing to do with MageBridge performance, but everything to do with Magento performance. Notorious are slow cache mechanisms or slow databases.

After the Magento app has started, MageBridge will initialize some settings, which normally does not take up much time - this is logged under MB_Core::init(). After this, MageBridge checks what needs to be done: Generate Magento block-output, login users, synchronize settings, parse content. When this is all done, the HTML-output will be sent back to Joomla! - just before this, MB_Core::output() is logged.

The time spent between MB_Core::init() and MB_Core::output() depends heavily on your specific MageBridge configuration. If only the Magento content-block (used in the Joomla! component-area) is fetched, time is minimal. But if the MageBridge Products module, MageBridge Category Menu module or other modules are turned on, additional time is required. To minimize this time, you might consider enable Joomla! caching so that Joomla! module-output is cached.

No exact numbers

Important to note is that, when you start calculating with the exact number of milliseconds spent on each time, you are unlikely to make everything match. Various milliseconds are lost by the debugging itself, various code-executions, etcetera. Therefor, the benchmark procedure described in this whitepaper is not ment to generate exact numbers, but to give you an indication on which performance-countermeasures to take where.