Magento

Hi -

We’re about to go live but we have one big issue PERFORMANCE. I have looked at all the performance threads and we have done all the optimizations however our CPU spikes at 100% when hitting any page. We have tried switching OS platforms without any success. Either IIS or apache will consume 100% of the CPU when a page is hit.

I have turned on profiling on Magento to see what’s causing the issue. In looking at the profile with KCachegrind it seems that all time if used in the Varien_Simplexml_Element->extendChild operation. At 97.78% of the time. This seems very high.

Has anyone ran into this issue as well? We’re using the latest Magento code base.

Thanks

Henri

Hi Henri,

It’s not a problem I have come across.  How many products, categories, stores do you have set up, also, what are the specs of your server?

Here are some stats:

Products in the catalog: 5292
Prices kept at website level:
Categories: 20
Stores: 166

Server specs:
CentOS 5.2 machine with Apache 2.2.x and PHP 5.2.x

henriv - 24 March 2009 06:26 PM

Here are some stats:

Products in the catalog: 5292
Prices kept at website level:
Categories: 20
Stores: 166

Server specs:
CentOS 5.2 machine with Apache 2.2.x and PHP 5.2.x

O.K.  that doesn’t sound like a typical setup for Magento.  It seems you have quite a lot of products, and a surprisingly large number of stores.  (websites I have worked with have less than 2000 products, and less than 3 stores).

You mention about prices being kept at the website level, what about all your other product attributes?

You didn’t mention what your hardware was, maybe you need to upgrade the specs

Magento has terrible performance issues, if magento is the ecommerce for growth, then 5000 products, should not be an issue. 

I have setup a store with 5000+ simple products and about 1000 grouped to represent them and 3 stores, and on a dual core operton with 2gig ram and sql caching etc.... Dedicated server , it always hits max cpu, well more like 54% since it seems mySQL and Apache just use one core of course per connection, so the dual core don’t help with single hits but should help with more than one person accessing it.

Importing products, especially 5000 or updating attributes takes Hours, and if you even updated 10-20, during that time cpu will be near max and anyone visiting the site may get ultra-slow preformance....  using SQL directly however, takes minutes to do the same task. 

it hits 100% cpu even with very little products anyways.  Magento’s uses zend which is a slow framework, plus the DB design isn’t designed for speeds sake, its just normalized to death.

You’ll just have to live with it, or switch ecommerce systems.

This is exactly what we have seen as well. We had to change our product import to writing php to perform direct imports into the mysql database vs. doing a Magento import. I have run the php profiler and KCachegrind on the code as it’s executed and it seems that Magento spends 97% of it’s time in the XML area. The mysql side seems to be fine, could use some optimization, and returns fast but it’s the PHP / XML side that’s doing all the heavy processing.

As such I wonder if the Magento team has looked at optimization this, by say reducing the need for transferring XML tree or caching XML or using a different XML library.

We were also about to go live but have found the same problem under load with 4 cores 2.2 ghz it just needs 2 users and the CPU runs at 100%. With 30 users the site dies.

We have done all the possible optimization and in the process of moving to another host with faster server...do you think this will solve it?

We have 1 store and 400 products.

Any news on this yet?  We have just one test store to get all setup in preparation to switch over to Magento.  However, I don’t see how we can make the move if we have 4 websites that need to run Magento when 1 user in the front end is maxing out our system memory.  Our current cart does not even come close.  There has to be some solutions.  I will buy a new dedicated server to replace our current one if I knew it would solve the problem.

Tim D.

Looks very good. Would like to see the entire source code if possible.
Home Protection Systems