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.
Products in the catalog: 5292
Prices kept at website level:
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.
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.
Heh, dedicated server, quad processor and at a minimum 4GB RAM.
Since it’s multiple stores, you probably need more iron as the number of HTTP server processes necessary to handle all the requests will eat up a bit of memory.
You’re trying to run an enterprise level operation, and it’s no surprise you need enterprise level equipment.
Rule number 1. Quit using Apache as a PHP interpreter. Either switch to FastCGI operation or change to using LiteSpeed or Nginx so the HTTP servers are HTTP servers and the PHP interpreting is split out into a separate process.
Changing to LiteSpeed which runs the php interpeter under lsapi processes and implementing APC for pcode cache has done the most for us. You might look into TinyBrick’s caching products as well. Anything you can do to get Magento away from compiling PHP code helps. As does lots of heavy iron.