140

Is Magento usually so terribly slow?

This is my first experience with it and the admin panel simply takes ages to load and save changes. It is a default installation with the test data.

The server where it is hosted serves other non-Magento sites super fast. What is it about the PHP code that Magento uses that makes it so slow, and what can be done to fix it?

Prashanth Shyamprasad
  • 827
  • 2
  • 17
  • 39
mr-euro
  • 2,732
  • 5
  • 23
  • 27
  • 12
    What hardware are you running it on? Magento needs some serious hardware backing in my experience. – jitter Oct 28 '09 at 18:35
  • 4
    I am not asking for support, but code. My hope was that someone had experienced this in the past and had optimised the code to avoid such sluggish behaviour. I do not have a specific snippet of code to point at since it is applicable across the entire site. I will have to look further into the matter. – mr-euro Oct 28 '09 at 18:43
  • @jitter How much is "serious hardware"? – mr-euro Oct 28 '09 at 18:44
  • 19
    Magento has 6000+ class files and is build for corporate use not for home use. Without APC don't event think about installing it. I am not recommending it for small shops. – Elzo Valugi Mar 11 '10 at 10:00
  • Agreed with jitter and elzo. Zend Framework itself needs some pretty hefty hardware without APC and Magento is built on top of that. – typeoneerror Jun 01 '10 at 22:01
  • Hello mr-euro, I don't know if you still got the issue, but I had similar issues and I solved them with this http://oldwildissue.wordpress.com/2011/11/29/boost-magento-performances-managing-the-two-level-cache/ – Matteo May 24 '12 at 13:24
  • This type of question doesn't really belong on Stack Overflow, as it's not a programming question. You should take a look at http://area51.stackexchange.com/proposals/25439/magento and see about getting a proper place to put these kind of questions – Sturm Aug 02 '12 at 18:21
  • You can speed up your catalog using [EcomDev Url Rewrite module](http://www.ecomdev.org/2011/10/08/ecomdev-breaks-magento-speed-limits.html). – Roman Snitko Dec 27 '11 at 14:22
  • Bottom line: You are probably on a minimal server. Magento needs REAL hardware (2-4 GB RAM minimum, 2 CPU cores minimum, fast disk).... A $40/month hosting plan will not cut it. – Jonesome Reinstate Monica Oct 28 '13 at 17:02
  • 1
    Regarding your flag, @Jonesome: this question is very broad and... probably somewhat dated at this point. That said, we do now have a dedicated site for Magento issues ([magento.se]), which would likely be a good resource for anyone working to optimize their setup. – Shog9 Nov 04 '13 at 05:06
  • 2
    @Shog9 I manage a team that develops and supports add ons for magento. I can tell you that this exact issue comes up almost daily. Magento is not a "normal" lamp app, in that it is very (very) resource intensive. This thread is important. Closing it forces this common conversation off of SO, which is unfortunate for all. – Jonesome Reinstate Monica Nov 04 '13 at 15:33
  • 1
    @Jonesome: as I mentioned, we're hoping to serve the Magento community a bit more effectively with its own, dedicated site - which [includes many questions on improving performance](http://magento.stackexchange.com/questions/tagged/performance). Keep in mind, Stack Overflow isn't really aimed at system planning or administration, which is fairly critical for this topic - IMHO, it's *always* best to examine performance issues holistically. Beyond that, if you strongly feel that this question is important to have on SO, raise the issue on [meta] & see if the folks there are able to help. – Shog9 Nov 04 '13 at 15:39
  • @Shog9 So move this thread to the magento SE site? (IMO, the proliferation of SE sites is perhaps not a good move, but that seems to be what the SE masters desire) – Jonesome Reinstate Monica Nov 04 '13 at 15:50
  • Like I said, @Jonesome, bring it up on meta - or better yet, on [Magento's meta](http://meta.magento.stackexchange.com/). We wouldn't migrate something like this until the site graduates in any case, but it may be worth discussing. See also: http://meta.stackexchange.com/questions/152597/how-to-migrate-old-questions-to-a-new-graduated-site – Shog9 Nov 04 '13 at 15:54
  • You can try this - not guaranteed to work but has helped a lot of people: http://inchoo.net/ecommerce/magento/boost-the-speed-of-your-magento/ – Marlon Creative Oct 28 '09 at 19:09
  • 1
    A better question is "why use magento at all?" – catbadger Nov 05 '19 at 20:17

11 Answers11

186

I've only been tangentially involved in optimizing Magento for performance, but here's a few reasons why the system is so slow

  1. Parts of Magento use an EAV database system implemented on top of MySQL. This means querying for a single "thing" often means querying multiple rows

  2. There's a lot of things behind the scenes (application configuration, system config, layout config, etc.) that involve building up giant XML trees in memory and then "querying" those same trees for information. This takes both memory (storing the trees) and CPU (parsing the trees). Some of these (especially the layout tree) are huge. Also, unless caching is on, these tree are built up from files on disk and on each request.

  3. Magento uses its configuration system to allow you to override classes. This is a powerful feature, but it means anytime a model, helper, or controller is instantiated, extra PHP instructions need to run to determine if an original class file or an override class files is needed. This adds up.

  4. Besides the layout system, Magento's template system involves a lot of recursive rendering. This adds up.

In general, the Magento Engineers were tasked, first and foremost, with building the most flexible, customizable system possible, and worry about performance later.

The first thing you can do to ensure better performance is turn caching on (System -> Cache Management). This will relieve some of the CPU/disk blocking that goes on while Magento is building up its various XML trees.

The second thing you'll want to do is ensure your host and operations team has experience performance tuning Magento. If you're relying on the $7/month plan to see you through, well, good luck with that.

cfx
  • 3,311
  • 2
  • 35
  • 45
Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • 10
    Thank you for the extensive explanation. Magento is indeed very powerful while allowing for flexibility. I initially thought it was simply the DB writes stalling due to some badly written SQL, but I do realise now that there is much more going on behind the scenes that initially expected. As a note: caching was disabled due to products being added by the shop owner. When cache was on he complained of products not appearing forcing me to disable caching while the shop was being set up. It is being hosted on a dedicated server, but it seems I will have to move Magento to its own exclusive box. – mr-euro Oct 30 '09 at 10:37
  • 4
    I profiled it a while ago with XHProf. The XML parsing took a huge amount of time - I think you are spot on with this list. – Morgan Tocker Jul 19 '10 at 18:34
  • 1
    I was wondering if running Magento on HHVM would make this any better. Last I checked HHVM doesn't support Magento, but if it were done, would that help? – Bharadwaj Srigiriraju Jan 21 '15 at 12:28
  • 1
    This explains a lot. Knowing is half the battle. I don't see how this could not be considered constructive. – flcoder Jun 13 '16 at 13:54
  • Don't forget optimising composer's autoloader files (see magento performance guidelines), if you use composer, and - for Magento2 - switch on production mode! Varnish is also a very good idea, providing your application does not have issues with full-page cache. – Dmitri Sologoubenko Mar 25 '19 at 20:19
55

Further to Alan Storm's recommendations on caching, there's two things I'd specifically recommend you look into related to caching:

- Make sure caching is in memcached, rather than on disk.

I look after a couple of magento installs, and once you get any sort of load on the system, memcached starts to perform much faster. And its dead easy to change it over (relative to doing other magento stuff at least!)

Good starting point is here: http://www.magentocommerce.com/boards/viewthread/12998/P30/ - but if you've not used memcached at all before, its worth looking at some general info about it as well.

- Enable template/view caching.

This is a good article: http://inchoo.net/ecommerce/magento/magento-block-caching/

There are good ones on the magento site too (google magento block caching), but its down at the moment.

To add my two cents to the block caching, I'd advise you create your own blocks in /app/code/local, extending the core ones and defining the cache parameters, name them xxx_Cache and then update your layout to use these blocks instead of the core ones. This way, you avoid losing your changes or breaking the system when you upgrade magento.

benlumley
  • 11,370
  • 2
  • 40
  • 39
  • 3
    Thx for the points. I will have a look at memcached which I have not used in production before. Good idea about cloning the blocks too. – mr-euro Oct 30 '09 at 10:30
  • 3
    I second what benlumbey said, I don't use memcached as I'm running windows server , but I store the /var directory in a solid state drive and that has made a big difference for me. – Rick J Nov 02 '09 at 05:15
  • @rickj - yeah, anything to make ./var folder faster definitely helps, i've tried using tmpfs before memcached as well, and got a decent boost off of that too. – benlumley Nov 02 '09 at 19:28
  • I would add to use apc cache for just a single node as it seems to have less overhead then memcached for multi node environment. – sbditto85 Dec 14 '12 at 17:51
  • 2
    Yes - true. But there are some caveats there, depending on how you run PHP, you can end up with a separate APC cache for every PHP process - which gets even less optimal if you are cycling your PHP processes every X requests. – benlumley Dec 17 '12 at 11:26
23

If you haven't seen it yet, Magento and Rackspace teamed up to create a white paper on performance tuning Magento. It's excellent. https://support.rackspace.com/whitepapers/building-secure-scalable-and-highly-available-magento-stores-powered-by-rackspace-solutions/

--- edit ---

Another great resource, newly available (Oct 2011) is: http://www.sessiondigital.com/assets/Uploads/Mag-Perf-WP-final.pdf

(Thanks due to Alan Storm on this one.)

Laizer
  • 5,932
  • 7
  • 46
  • 73
18

There is possibly also a very non-obvious reason why your admin interface is very slow. Magento has a module named Mage_AdminNotification. Try to disable that ext. Because what it does is query magentocommerce.com for new update messages. If their servers are slow your admin page waits and is in effect slow because of the network lag and loading of the external news. If you have secured your outgoing server connection through a firewall this can be even more frustrating, since the admin interface will wait for the timeout when it cannot reach magentocommerce.com

To disable it: go to System -> Configuration, scroll to the bottom and hit Advanced(in the Advanced section). Now disable Mage_AdminNotification and save!

Sam Figueroa
  • 2,301
  • 22
  • 21
  • 4
    This made a significant different in performance on my local dev environment, which had always frustrated me how slow it ran on a very fast development box. Thank you! – random_user_name Apr 21 '13 at 21:58
  • In Magento2: Stores->Configuration->Advanced->Advanced, then disable `Mage_AdminNotification`. – Scott C Wilson Jul 23 '17 at 04:09
6

I'm more involved in the managed server optimization in my company but I may have a few tips for you. First, you can look at the code more closely using the code tracing feature of Zend server. It will allow you to see where and when the things get dirty.

I totally share benlumley's consideration regarding the cache. Most of the sites we host doesn't even have the block caching enable. This cache has to be explicitly called and not "assumed". So if you code hasn't yet took part of this mechanism, it's something you definitely want to try. If you have a EE version, you can get the Full page up in order to get the best of the beast.

A reverse proxy will also help a lot. It'll cache the static ressources, significantly lowering the pressure on the php interpretation stack of your front servers.

Don't forget to write the sessions & Magento cache to a RAM disk. This will also definitely get you to another level of performances.

There's still a lot to be said here but I'm running out of time. You have to know that a good site, well coded in a 1.4.1 CE version, running on a 2x5650 Xeon + 16 GB RAM server and having a Rproxy on top can take up to 50 000 unique visitors a day with smooth pages to everybody.

Emil Vikström
  • 90,431
  • 16
  • 141
  • 175
kameo
  • 61
  • 1
  • 1
6

I only have a superficial experience with Magento. I installed it on a shared grid-server and the page loading was dismal ~5+ seconds. On a lark, I installed it on my optimized for CMS sites dedicated server, and it felt very, very snappy.

My Dedicated hosting had ~10 Joomla! sites and a VBullitin site running.

My guess is it's just not going to be performant on shared hosting. The over-subscription just won't allow enough resources for Magento to run as it ought.

creuzerm
  • 820
  • 7
  • 14
5

Switching from Apache to LiteSpeed helped us a lot. In addition to: Editing MySQL's settings, installing Fooman Speedster (module to compress/combine js and css files), and installing APC. Magento has also posted a white paper on how to get the best performance out of the enterprise edition, but it is equally applicable to the other versions: http://www.magentocommerce.com/whitepaper/

Jonathan
  • 307
  • 2
  • 6
4

There are many reasons why your Magento shopping cart could be running slow but no excuses for there is a variety of ways to eleviate the problem and make it pretty darn fast. Enabling Gzip by modifying your htaccess file is a start. You can also install the fooman speedster extension. The type of server used also will determine the speed of your store. More tips and a better explanation here http://www.interactone.com/how-to-speed-up-magento/

Thomas
  • 41
  • 1
4

Magento is very slow because the database design is not very good. The code is a mess and very hard to update and optimize. So all optimizations are done via cache instead of code.

On the other hand. It is a webshop with a lot of tools. So if you need a flexible webshop just buy a very powerfull server and you will be ok.

developer
  • 93
  • 1
  • 1
    The database design is actually very good and flexible. – Black Sep 15 '18 at 15:56
  • That's certainly debatable. There's a lot of missing primary keys (yes, primary keys are missing in some tables) and indexes and inconsistent namings. – danronmoon Dec 06 '20 at 19:55
4

When I first installed I had pages that were taking 30 seconds to load. My server was not maxed out in ram or processor, so I didn't know what to do. Looking at firebug's net panel it was loading about 100 files per page, and each one took a long time to connect. After installing fooman speedster and the gzip in the htaccess loads times were down to 3 seconds, like they had been on other shopping carts on my server.

Scott
  • 41
  • 1
3

it will also come down to functionality versus performance.

Raw performance is gained using nginx, php-fpm, memcached, apc and a proper designed server.

Functionality like plesk and magento performance could be managed by taking the entire infrastructure in perspective when designing a magento performance cloud.

ProContractors
  • 39
  • 2