Category: Bug Fixes
An issue you may encounter on larger sites is massive DB load spikes when there is a high order volume and large number of customers stored in the DB. The problem stems from the Enterprise Edition’s Customer Segments module and the way it checks to add a new customer into a segment.
The main culprit is the Enterprise_CustomerSegment_Model_Segment_Condition_Combine_Root class, specifically the _prepareConditionsSql method. This is what generates the SQL that will be run to verify if a customer should be added to this segment when they place an order or sign up. It generates a query like:
SELECT 1 FROM `customer_entity` AS `root` WHERE (( IF(( SELECT 1 FROM `sales_flat_order_item` AS `item` INNER JOIN `sales_flat_order` AS `sales_order` ON item.order_id = sales_order.entity_id INNER JOIN `core_store` AS `store` ON sales_order.store_id=store.store_id WHERE (sales_order.customer_id = '11111111') AND (store.website_id='1') AND (EXISTS (SELECT `main`.`entity_id` FROM `catalog_product_entity` AS `main` WHERE (main.sku = 'ITEM1') AND (main.entity_id = item.product_id))) LIMIT 1 ), 1, 0) = 1 ))
which has a major issue, the main outer query has no limit! Even worse, it has no where condition to limit the number of rows being returned so what you get is a HUGE amount of rows containing “1” whenever the inner customer+item match is true. When you have 1 million or more customers, this can lead to the DB creating temporary tables on disk since it no longer fits in the maximum memory temp table size which leads to load spikes if you are getting any sizable amount of orders being placed. Continue reading
If you use Magento EE and have enabled Solr for search, you may run into a few issues depending on how you customize your template. One issue is that the Enterprise Search engine for Solr does not properly handle resetting the result count when 0 results are found. The other two have to do with the way it indexes the data; it does not properly add some attributes to the index if you only have “Used for Sorting in Product Listing” enabled and/or they are the datetime attribute type on non-simple products.
The first one is relatively easy to reproduce but probably is not run into very often. On a website I was developing, the client wanted to break out the search results into individual categories and display the top few of each category results on the page. The page would then link out to each individual category to view all the results inside that category. The problem we found was that, if the previous category returned results and the current one it was outputting had none, it would still think that it had the same number of results as the previous category.
This is something we ran into during the testing of a new Magento website. We started getting “Payment Transaction Failed Reminder” emails from the system. The client reported that they would just be presented with an error message during checkout when they tried to place the order and it would just keep returning the error no matter how many times they tried to submit it.
Looking at the email sent by the system, the error message being returned was:
SQLSTATE: Integrity constraint violation: 1062 Duplicate entry ‘T000112’ for key 2
After investigating a bit, I found that someone else had already placed an order and taken that increment_id which is why this order was returning an error. This was a bit odd since Magento is supposed to be keeping track of these things and automatically ensure order numbers are never the same. Even looking at the sales_flat_quote table showed two entries with the same reserved_order_id which should not happen.