预告中的性能测试，结果我不想贴了，因为改造前后实在是看不出明显差距（用的Apache的ab）
。这个结果其实有心理准备，或者说在预料当中。虽然配置文件的加载（config.xml等）在Magento接收一个请求的整个进程中影响不小（处理时间和内存占用），但我这次的改造对配置文件总量的缩减不够明显，对最后结果的影响自然就不明显了。
瘦身效果多不明显，有数据为证，用Alan大神的Configviewer模块分别记录下改造前后的总配置文件(聚合之后)，改造前的xml总行数（拷贝到编辑器格式化之后，后面同理）是9465行，改造之后（删除我所谓的所有可被约定所替代的配置）的总行数是8718行，瘦身的百分比只有大概8%，这个程度的瘦身，再加上我为了实现“按约定加载”所添加在核心的php代码的影响（负面影响）抵消，最终的结果也就很好理解了。
这次的折腾到此为止确实是很像一次玩票，不过我倒是没有觉得所花的时间是浪费的。首先，再一次读了下Magento的核心代码（以前也看过，但没想那么多），核心代码写得好的部分可以学习，写的不好的部分也可以学习（作为反面例子），无法判定好或坏的部分，也可以作为思考的源泉。其次，我依然认为Magento某些方面有过度设计，与“约定优于配置”这个流行的思想不一致，虽然我之前做的改造没有取得明显的效果，但一方面除了前面指出的这些，Magento必然还有不少地方值得改造，需要时间和工具（比如APM）去挖掘，另一方面改造的思路没错，但我个人写的实现这个思路的具体代码本身可能还没有做到性能最优（越是底层的代码，对系统的整体性能的影响越大，特别是有并发的情况下）。通俗点讲，道路虽然是正确的，但路还是要一步一步走出来的。
前面说到配置文件的加载对一次系统请求影响不小，其实有另一个很简单的方式去瘦身，这个方式算是Magento的常识之一，也是很多新手很容易不注意的地方（或者觉得无关紧要而忽视的）。这个方式就是关掉你所不需要的Magento模块，关闭的方式是去找app/etc/modules下面的xml，找到对应的模块定义，把模块状态改为false（或者直接删掉该文件）。以做中文站为例，在国内用不到的支付方式（paypal等），配送方式（dhl等）所有对应的模块都是可以直接关闭的。以Phoenix_Moneybookers模块为例，在上面的改造后基础上，仅仅是关闭Phoenix_Moneybookers模块，总配置文件的xml总行数就从8718下降到了8544行（我的改造费老大劲也就干掉了不到一千行
）
<config>
<modules>
<Phoenix_Moneybookers>
<active>false</active>
<codePool>community</codePool>
</Phoenix_Moneybookers>
</modules>
</config>
每个基于Magento做的网站都有各自不同的特性，国内或国外，食品或衣服，大众商品或个性商品等，所以就Magento自带模块（先不讨论第三方模块）来说，每个网站都会有一些自带模块是用不到的，A网站需要用A模块而不需要B模块，而B网站需要用B模块而不需要A模块等。关闭掉自己不需要的模块是强烈建议做的一件事，前面提到有些新手觉得这个无关紧要，是因为没有意识到关闭无用模块对性能的提升其实挺明显。有点扯远了，关模块这个其实是另一个值得一讲的话题，有时间可以单独写一章讲一讲。
