How much memory does Magento use?

So, I was teaching the Magento Performance for System Administrators class the other day.  I’ve delivered the class several times but this is the first time that somebody asked me “How much memory does Magento actually use?”  Now, I know what you’re supposed to set it at, but I’ve never measured actual usage.  So I gave some bullcrap answer about how it really depends on a bunch of things and that I really shouldn’t give a precise answer.  But the individual persisted and I was forced to put my tail between my legs and admit that I didn’t know.

So I promised that I would take a look and here are my results.  I’m sure someone will get their panties in a wad about how it doesn’t do this, that, and the other thing. The purpose of these tests were to give a baseline and that’s it. I expect that an actual catalog implementation will have consumption values higher than what is seen here.

The way I measured the memory usage was that I added some code to Mage_Core_Model_App::dispatchEvent() and took memory measurements each time an event was triggered.  I called both memory_get_usage() and memory_get_usage(true).  I also injected a marker at controller_action_predispatch, core_block_abstract_prepare_layout_before,  core_block_abstract_to_html_before, resource_get_tablename, and controller_front_send_response_after.  The reason for that is so that I could get visual cues as to which part of the execution (controller, layout prepare, layout render) was responsible for each.

The Y axis is memory used in MB.  I divided the memory_get_usage() values /1024/1024 to get the the MB used.  Additionally, because the events were used as the sampling point the X axis represents the event count, not elapsed time as your brain might think.

The data that I used was the Magento sample data.  While it is unrealistic to have such a small catalog in Magento it is the only consistent data that is really available.

The first mark is the start of the request.  The second is controller_action_predispatch.  The second is core_block_abstract_prepare_layout_before.  The third is core_block_abstract_to_html_before.

At this point I had realized that I had not copied the sample media over.  So I re-ran the request with the media.

There were only 5 products in this category so I wanted to run a page that had pagination.

Obviously there were some images being re-sized here. But actual usage, while higher, was not overly significant.

Then, of course, there is the question of product pages

There was no real difference between any of the other product types.

Adding to cart was relatively benign.

As was displaying the cart ( a 302 Found done after adding to cart).

While it is a little difficult to read, here is a chart that shows several of these charts in comparison.

A couple of takeaways from this

1. Image processing sucks up memory and could allocate more than memory_limit
2. Layout generation generally uses the most memory.
3. From a memory perspective, the product type does not seem to do much to memory consumption
4. From a memory perspective, the number of items in a category does not seem to have much impact in memory consumption
5. If memory is an issue, layout XML optimizations might be a valid place to look to reduce usage

However, it bears mentioning

1. This test did not test very large collections
2. This test did not test very complicated layouts
3. This test did not test catalog or shopping cart rules
4. This test did not test performance
5. And a bunch of other things.