Author: 芳草苑主

There are some website benchmark tools, looking after various aspects of performance.

The tool I use most is Apache Benchmark, and parameters are 10 concurrencies, e.g.

ab -c 10 -n 200 (page_url)

It reflects the status quo. I have a decent server but the sites are not busy.

Since I dived into Magento, I have been spent quite a lot researching how to improve its speed. I implemented database query cache, enabled block html cache, utilised memcache, tmpfs, apc, etc, etc. Recently I started a project called Full Page Cache Preparer (FPCP) and expected it fundamentally improve Magento speed on Catalog and Cms pages.

FPCP is only 20% completion (it is not producing all blocks with session variables, but shopping cart sidebar), but I am eager to see some result. So I turn it on and compare the Requests Per Second to the time when it is off. I see a marginal 1-2% improvement which is very disappointing.

Why I had the impression that full page cache feature will dramatically drive Magento faster? What if full page cache is working with web server cache, say nginx ncache? I simulate a test by saving a page html source code to a static file and uploading it to web server. (I should have done this test before I started FPCP project.) The result is disappointing, again.

The test is done on a heavy page (with loads of images).

The figures in first two columns (ADSL connection) go up and down when I run tests again and again. Sometimes requesting a static file is even slower than requesting Magento index.php. My conclusion is, even when Magento full page cache is working in conjunction with nginx ncache, I cannot feel the sites are faster (when the server load is not high).

However, I will finish my FPCP module (some day) because I believe it benefits people whose server load is high. To improve my own sites, I will focus on basic (if I call FPCP hi-tech) page speed recommendations, e.g., optimise images, concurrent downloads, cookieless domains for static files, merge js/css files, gzip, etc.

Magento did not mention this (or hide somewhere I could not find), so I’d like to mention it:

Magento helper class is a singleton desin pattern. Whether a helper class is called in a format as

Mage::helper('mymodule')->helperMethod();

or as (in a block class or a template),

$this->helper('mymodule')->helperMethod();

the helper class is only initialised once.

Which means Magento puts a singleton desin pattern on helpers.

今天发现，我的所有的 admin controller 都写成了 extends Mage_Adminhtml_Controller_action。虽然不影响使用，我还是想把它改规范的驼峰式 Mage_Adminhtml_Controller_Action。

于是搜索了整个硬盘到底哪些文件里包含 Mage_Adminhtml_Controller_action，结果发现这个笔误还不少。而且不光我写的 modules 里有，Aheadworks, J2t, Plieninger 的代码里也有，最后发现源头是 koukou1985 的 Magento module creator。

看来 Magento module creator 流传甚广。

Magento EAV framework is very promising, but not easy to understand. When the code is mixed with typos, it becomes even more confusing.

Mage_Catalog_Model_Resource_Eav_Mysql4_Setup provides a template for setting up an attribute.

'name' => array(
'type'              => 'varchar',
'backend'           => '',
'frontend'          => '',
'label'             => 'Name',
'input'             => 'text',
'class'             => '',
'source'            => '',
'global'            => Mage_Catalog_Model_Resource_Eav_Attribute::SCOPE_STORE,
'visible'           => true,
'required'          => true,
'user_defined'      => false,
'default'           => '',
'searchable'        => false,
'filterable'        => false,
'comparable'        => false,
'visible_on_front'  => false,
'unique'            => false,
)

However, ‘class’ is wrong. It should be ‘frontend_class’. It refers to DOM class attribute assigned to this entity attribute output html. It can be used for value validation before submission. The possible classes can be found in js/prototype/validation.js. But frontend_class can be set anything you like for css styling or other purposes.