Magento的靈活性帶來的負擔一例

Magento的架構設計的非常靈活，官方的考慮是希望架構能夠適應可能遇見的所有情況，其中最重要的一部分是EAV模式的設計（也是被很多人又愛又恨的一塊）。在實際應用中，每個網站總是有各自實際的固定情況，而不用像官方做產品那樣去照顧方方面面，這個時候靈活的架構設計有時候反而會成爲系統性能上的負擔。不過我給的這個例子不是跟高大上的EAV相關的，也不一定是實際應用中最需要改的位置，只能算是拋磚引玉，給別人也給自己提個醒。

用Magento搭建的賣服裝的網站，一般會用可配置商品（Configurable Product）來管理商品，選擇顏色和尺碼（原生不自帶）屬性來做配置項。Magento系統的可配置商品理論上可以用三個，四個甚至更多個屬性來作爲配置項，因此它的代碼結構設計上支持可配置商品用無限多個屬性配置項，而實際業務中，可配置商品最多會用到兩個屬性配置項，比如服裝類的顏色和尺碼（不排除有少數特殊的品類會用到多個，但總歸是有限的），這種情況下原生的代碼在性能上可能就會成拖後腿的了。

if ($this->_isStrictProcessMode($processMode)) {
                    foreach($this->getConfigurableAttributes($product) as $attributeItem){
                        /* @var $attributeItem Varien_Object*/
                        $attrId = $attributeItem->getData('attribute_id');
                        if(!isset($attributes[$attrId]) || empty($attributes[$attrId])) {
                            $subProduct = null;
                            break;
                        }
                    }
                }

上面這段代碼出自Mage_Catalog_Model_Product_Type_Configurable裏的_prepareProduct方法，目的是爲了在商品加購物車時驗證接收的參數中，屬性id（比如顏色默認是80）是否與該可配置商品所含有的配置項屬性對應。爲了取出商品包含的兩個屬性的id（以顏色和尺碼爲例），這裏使用了getConfigurableAttributes這個方法來動態的從數據庫中獲取。而事實上，在網站實際運作中，我們後臺添加完屬性時就已經知道了這倆個屬性的id（顏色系統自帶，id爲80，新增的尺碼在我的開發環境裏id是133），沒有必要再一次從數據庫中去獲取。

可能有人覺得從數據庫獲取一下這個數據所帶來的負擔微不足道，一方面我上面已經提到只是舉個例子，做個拋磚引玉，提醒下大家在開發中可以考慮這個優化角度，另一方面，這個例子其實還是特地挑出來的，getConfigurableAttributes這個方法附帶連鎖的代碼有不少，當顏色屬性的選項數超過40個時，每次添加購物車時，這段代碼會造成多0.4秒的時間消耗（本機開發環境實測），如果顏色和尺碼屬性各自的選項數量更大時，這段代碼所消耗時間還會更長，相比直接硬編碼已知的id80和id133，區別已經到了肉眼可見的程度。至於爲什麼getConfigurableAttributes方法會有這種情況，我這裏就不細說了，有興趣的可以研究下源碼。

回到主題，Magento的架構設計的很靈活，當你自己的網站在某些方面不需要那麼靈活時，適當的改造靈活代碼爲硬編碼，也許剛好就能幫助你解決某個困擾已久的性能瓶頸。以上是我的個人見解，歡迎拍磚。