For example, I recommend disabling Mage_Rss to speed up checkout processes since Mage_Rss isn't widely used and forces cache cleaning multiple times per checkout request.

I'm evaluating disabling Mage_Log for similar reasons -- I already have Google Analytics in place as well as aggregating apache logs via PapertrailApp.com, but I realize I haven't formalized my process for checking on the ramifications, so feel free to answer specifically for Mage_Log or generically for disabling a core module.

I know I can determine the tables a module uses by looking at its installer script in /sql, and the events it registers by looking at \etc\config.xml, but what else is pertinent? Is this module reasonably encapsulated in only affecting the tables with prefix log_? There are several events defined by this core module, will their observers fail gracefully/silently or cause downstream issues? How do I tell what reports, if any, are impacted?

  • 2
    The first thing from the top of my head is Customers\Online Customers is fed from some log_* tables. Commented Feb 7, 2013 at 15:43
  • You may want to take a look at this. Thomas Birke created an extension for tweaking Magento's core performance per a great talk given by Ivan Chepurnyi: github.com/quafzi/magento-performance-tweaks by tegan-snyder Commented Dec 29, 2013 at 19:28

3 Answers 3


Aside from the obvious, e.g. the module no longer working - a potential side-effect is any module that has that core module listed in their declaration would also not function. There are many 3rd-party plugins that depend on core modules loading. There are core interdependencies, too, especially if you're using Enterprise.

I'm under the impression that most people disable these 'unnecessary' modules for speed purposes - after all, only load what you use, right? While I'm sure it has some small, measurable impact - there are much more effective things you can do to positively impact the speed of your site.

There are some great SO articles out there that talk about this particular issue - this one in particular seemed like a good read to me:

Speed Optimization by disabling Mage_Reports module?

There are other reports out there that disabling Mage_Downloadable, etc. may help in Checkout - but these seem to be aging posts and aren't relevant in my opinion to the latest releases of Magento. If you're still running on 1.4CE or 1.7EE, this might be particularly useful to you.





It's hard to generalize what measureable impact this would have for your particular - or anyone's - situation. A slow-ish server on a low-bandwidth network, for instance, would impede your speed more greatly than any of the mentioned solutions.

Based on your own intensive analysis it seems it may profit you. As with all SO feedback, YMMV, but I think that using memcached, apc, full page cache and a CDN can have a more measurable impact to something like, say, conversion rate as it impacts the end-user experience.

I configure all client boxes based on the published whitepaper specs - to my knowledge they do not make mention of disabling unused modules. They do make mention of disabling unnecessary Apache Modules.



Lastly, I have done some digging and can only find mentions of disabling Mage_Rss as a potential performance boost when using filesystem cache. If you're using filesystem cache, and haven't at the very least mounted that to tmpfs, you should seriously consider memcached, apc, or the aforementioned tmpfs mount.

  • 2
    @philwinkie: Actually disabling Mage_Rss significantly reduces IO during checkout... it is a very beneficial tweak. Although it's obviously safer to just disable the observer. Commented Feb 6, 2013 at 22:06
  • @philwinkie: It's very tough to generalize what performance improvements are important for the many different use cases of Magento. My database server peaked at ~3200 write IOPS in the last 6 hours so I am pretty sure my best bang for buck improvement is to disable Mage_Log :)
    – Ralph Tice
    Commented Feb 6, 2013 at 22:23
  • Thanks for the updated answer. I already have memcached, APC and CDN in place. Full page cache doesn't help my particular use case for reasons I can't go into here, so I'm left with optimizing the codebase. Thanks for the pointer to Mage_Downloadable, I will try that one out also.
    – Ralph Tice
    Commented Feb 7, 2013 at 15:23
  • In the absence of FPC, I would look into Varnish Cache - specifically with the Varnish modules available on Magento Connect. Cheers.
    – philwinkle
    Commented Feb 7, 2013 at 18:41
  • Varnish won't help either. I simply have too many storefronts :)
    – Ralph Tice
    Commented Feb 8, 2013 at 1:55

We've seen a specific issue with disabling Mage_Log that it breaks Product Compare functionality. When anonymous browsers add to compare and then log in, Magento uses the visitor_id generated by Mage_Log to attach the compare list to the customer, and if this value is null then it breaks the site, hard, if any other customer has ever compared the same product_id (uncaught duplicate key exception).

  • Thanks for the info, Jonathan! Initially I wanted to disable Mage_Log completely, but now I'm going to disable observers only :) Commented Oct 30, 2013 at 15:58

Maybe you are interested in Magento Lite Project, this is basically Magento backbone ( the most of module has been disabled )


  • This fork of Magento is for CMS purposes and all shopping cart functionality was removed. The OP's question is in regards to speeding up checkout, so they need shopping cart functionality!
    – philwinkle
    Commented Feb 10, 2013 at 20:48
  • actually nobody will stop you to use it for cart purpose.. you just need to re-enable the modules that you need
    – Fra
    Commented Feb 11, 2013 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.