While researching Blackfire (https://blackfire.io) and its functionality, I decided to focus on Magento 1's category pages. Category pages are the most requested in the entire framework, so any performance improvement results in a better user experience when navigating the product catalog.
After running the initial profile on my local project environment, which only uses configurable products, I received the following results:
We see that our profile has a wall clock time of 15.8 seconds, which is disappointingly slow. Wall clock time is a calculation of your CPU (amount of time used for processing instructions) + I/O time (network + disk time). With these results, our page calls for further investigation.
Below is a screenshot of all the functions and sub-functions of the getConfigurableAttributes function, with a clear red path to follow.
We now see that our getConfigurableAttributes function has 3 callees, functions that are called from the current function. One of these functions is the Varien_Data_Collection_Db::load function, which uses 98% of all call time. A question we can ask ourselves, “Why is Magento 21 loading collections and is this necessary?”
We see that loading a collection class each time activates the afterload function, which in turn calls other functions and so on.... At the end of our path, we see that the attributesCompare function uses 39.65% of all times and is called 31122 times.
Let's take a closer look at each major function on the path so we have a better understanding of what is happening and why attributesCompare is called so often. We'll start with the function getAttributeById in the 'Mage_Catalog_Model_Model_Product_Type_Abstract' class.
All this function does is call the getSetAttributes to receive all the attributes for a specific product. It loops all the attributes until it finds the attribute that matches the attributeId parameter. If it is found, it returns the attribute. We know that the getSetAttributes function is the next important function on our path, so we continue our investigation by looking there.
This function returns all products of a specific product with the loadAllAttributes function, but also calls the getSortedAttributes function. This is the biggest problem as we can conclude from our Blackfire profile (47.23%).
This function checks which attributes are in the supplied attribute set and sorts them with the uasort function that calls attributesCompare. As mentioned earlier, this function is the final function on our path and needs improvement. We know that this function is repeated for every product, which is useless because a specific attribute set will always keep the same attribute order for every product that uses that set. Let's try to rewrite this functionality.
Unfortunately, this function is in an abstract Magento class, so a good rewrite is not possible. Instead, we need to override the entire class. We do this by placing the 'Mage_Eav_Model_Entity_Abstract' class in the 'app/code/local' pool on the same file path as the file in the 'app/code/core' code pool.
First, we add a static variable. This variable is used the first time the attributes are sorted and stores the results on a specific attribute set id index. This way, we no longer need to calculate the positions of these attributes when the same attributeset-id is specified. We only return the dataset of our variable.
Next, we modify the getSortedAttributes function and make the following changes.
We check if our key exists. If yes, we return the data. If not, we compute it and set the array index at the end for further use.
Let's re-profile our page and see if the changes had any effect.
We see a 45% wall clock time improvement across our entire page! Our CPU time is reduced by 48%.
Above is a comparison of the two profiles. The previous and current profile. The blue blocks indicate improvements with the wall clock time in seconds. A simple change with big effects. Of course, it is also possible not to view the profile in comparison mode.
Further improvements could be to load the collection once for all products instead of 21 times separately. Addressing the problem at the top of our red path is usually a better idea because each sub-function follows. Since in this case each product may have different configurable attributes, this may not be the best idea. Note that this is not the default list.phtml Magento template. Unlike this template, the getSortedAttributes function is core Magento functionality and can be a quick win for various Magento projects.
This problem was mainly a CPU issue, but you may have other factors that can cause problems. It's a good idea to check all tabs. Memory, Network, Http, Http, Queries, etc.... A good example are import/export scripts. These can easily cause CPU problems as well as memory problems. Let me give you an example of another case. This time about a Magento's varien core file.
When importing product images with one of Magento's cronjobs, an “out of memory” error occurred. I decided to use Blackfire's CLI this time because cronjobs can be time-consuming. Especially when dealing with import scripts. This profile was generated with the free version of Blackfire, so some tabs could have disappeared.
Above is the result of our profile. Note that this time we are looking at our data under the memory tab because our error is memory specific. Our path is now light blue instead of red.
The most time consuming function is the imagecratefromjpeg which is called only 32 times. This 32 represents the number of images imported before the memory error was thrown. We can also conclude that a new instance of the 'Varien_Image_Adapter_Gd2' is created for each image. The constructor of the varien_image calls the open function of this class, which in turn calls the imagecreatefromjpeg.
All these images are created and kept in memory, but nowhere removed from memory.
So it is obvious that these will error over time. Especially when importing many images. Let's see how we can modify the script to release our memory after each image import.
If we look at the open function of our 'Varien_Image_Adapter_Gd2' class we see that the current image is stored in a variable $_imageHandler.
It might be a good idea to destroy the image set in this variable after the class is no longer used. At that point, the image has already been imported, so we no longer need it.
Let's override the 'Varien_Image_Adapter_Gd2' class from our Magento 1 lib directory by adding the same class under the 'app/code/local/Varien/Image/Adapter/' path.
A good place to write our functionality could be in the destructor. This function will always be called during the exit sequence of a given object. We add the following code:
Here we activate the @imagedestroy function on our variable. Doing this destroys the image object and releases the memory. Let's re-profile our script and see the impact.
BLACKFIRE SILVER PARTNER
PHPro is a Blackfire.io Silver Partner. Blackfire enables all developers and IT/Ops to continuously verify and improve their application performance, throughout the lifecycle, by getting the right information at the right time.
If you need additional help, performance consulting to improve your PHP applications, don't hesitate to contact the PHPro PHP Performance Team.