php數(shù)組的方便性,很容易令人過度使用,其中一種過度使用的場合,就是做緩存時不區(qū)分場合濫用數(shù)組,導(dǎo)致性能不高,主要是集中在對CPU性能的高占用消耗上[1],以下以phpcms v9舉例說明.

phpcms v9中,作為模塊設(shè)計(jì)的pc標(biāo)簽[2]其實(shí)是不錯的,易于讓人理解而且功能強(qiáng)大，但偏偏在關(guān)乎效率的緩存上似乎沒有意識到一個問題,絕大部分的開發(fā)者使用pc標(biāo)簽的緩存參數(shù),其實(shí)質(zhì)是希望將該pc標(biāo)簽包圍的模塊進(jìn)行緩存,故而從緩存實(shí)現(xiàn)來講,作為一個視圖層而言,應(yīng)該緩存最終渲染的html才對；但phpcms卻只是緩存了數(shù)據(jù)數(shù)組,每次讀取緩存并還原為數(shù)組后,仍然要進(jìn)行渲染運(yùn)算,這樣的結(jié)果,導(dǎo)致了pc標(biāo)簽的緩存效率，其實(shí)沒有設(shè)計(jì)者想象的那么高.

比如如下pc標(biāo)簽:

1. {pc:content action=”position” posid=”1″ thumb=”1″ order=”listorder DESC” num=”5″ cache=”500″} 
2. <div class=”content” id=”main-slide”> 
3. <div class=”changeDiv”> 
4. {loop $data $r} 
5. <a href=”{$r['url']}” title=”{str_cut($r['title'],30)}”><img src=”{thumb($r['thumb'],310,260)}” alt=”{$r['title']}” width=”310″ height=”260″ /></a> 
6. {/loop} 
7. </div> 
8. </div> 
9. {/pc} 

其本意應(yīng)該是為了緩存該pc標(biāo)簽包圍的焦點(diǎn)圖片模塊,但是生成的最終代碼發(fā)現(xiàn),緩存的是中間從數(shù)據(jù)庫讀取出來的數(shù)組,仍需要每次渲染:

1. <?php if(defined(‘IN_ADMIN’) && !defined(‘HTML’)) {echo “<div class=/”admin_piao/” pc_action=/”content/” data=/”op=content&tag_md5=2e957216affd4b95207c8d8eabcfb7b8&action=position&posid=1&thumb=1&order=listorder+DESC&num=5&cache=500&htmlblockcache=1/”><a href=/”javascript：void(0)/” class=/”admin_piao_edit/”>編輯</a>”;}$tag_cache_name = md5(implode(‘&’,array(‘posid’=>’1′,’thumb’=>’1′,’order’=>’listorder DESC’,'htmlblockcache’=>’1′,)).’2e957216affd4b95207c8d8eabcfb7b8′);if(!$data = tpl_cache($tag_cache_name,500)){$content_tag = pc_base::load_app_class(“content_tag”, “content”);if (method_exists($content_tag, ‘position’)) {$data = $content_tag->position(array(‘posid’=>’1′,’thumb’=>’1′,’order’=>’listorder DESC’,'htmlblockcache’=>’1′,’limit’=>’5′,));}if(!emptyempty($data)){setcache($tag_cache_name, $data, ‘tpl_data’);}}?> 
2. <div class=”content” id=”main-slide”> 
3. <div class=”changeDiv”> 
4. <?php $n=1;if(is_array($data)) foreach($data AS $r) { ?> 
5. <a href=”<?php echo $r['url'];?>” title=”<?php echo str_cut($r['title'],30);?>”><img src=”<?php echo thumb($r['thumb'],310,260);?>” alt=”<?php echo $r['title'];?>” width=”310″ height=”260″ /></a> 
6. <?php $n++;}unset($n); ?> //Vevb.com 
7. </div> 
8. </div> 
9. <?php if(defined(‘IN_ADMIN’) && !defined(‘HTML’)) {echo ‘</div>’;}?> 

解決這種效率問題,最直接的方法是增加參數(shù),允許改為存儲整塊最終渲染的HTML模塊,為此,改造了phpcms,允許增加一個htmlblockcache=”1″參數(shù),前提是cache參數(shù)必須大于0,以解決此問題:

1. {pc:content action=”position” posid=”1″ thumb=”1″ order=”listorder DESC” num=”5″ cache=”500″ htmlblockcache=”1″} 
2. {/pc} 

受條件所限，ab測試只能在本機(jī)實(shí)驗(yàn)。測試環(huán)境為：Win 2003 + IIS 6 + php 5.2，沒有安裝任何opcode緩存擴(kuò)展。測試方法是：后臺更新（刪除）所有緩存后，在瀏覽器刷新首頁一次，以便重新生成所需緩存；首次兩輪-n 10 -c 10預(yù)熱，接著兩輪-n 600 -c 15正式測試，取第二次作對比。

測試結(jié)果發(fā)現(xiàn),改造后的響應(yīng)速度有提高不小,但是由于更新緩存時需要進(jìn)行ob緩沖,其響應(yīng)會偶爾偏高.

改造前（沒有htmlblockcache）的首頁測試結(jié)果:

1. Document Path: /phpcmsv9/index.php 
2. Document Length: 41900 bytes 
3.  
4. Concurrency Level: 15 
5. Time taken for tests: 33.891 seconds 
6. Complete requests: 600 
7. Failed requests: 0 
8. Write errors: 0 
9. Total transferred: 25286400 bytes 
10. HTML transferred: 25140000 bytes 
11. Requests per second: 17.70 [#/sec] (mean) 
12. Time per request: 847.266 [ms] (mean) 
13. Time per request: 56.484 [ms] (mean, across all concurrent requests) 
14. Transfer rate: 728.63 [Kbytes/sec] received 
15.  
16. Connection Times (ms) 
17. min mean[+/-sd] median max 
18. Connect: 0 0 1.9 0 16 
19. Processing: 156 843 361.4 906 1875 
20. Waiting: 141 839 360.8 906 1875 
21. Total: 156 843 361.5 906 1875 
22.  
23. Percentage of the requests served within a certain time (ms) 
24. 50% 906 
25. 66% 1031 
26. 75% 1109 
27. 80% 1156 
28. 90% 1281 
29. 95% 1344 
30. 98% 1453 
31. 99% 1516 
32. 100% 1875 (longest request) 
33.  
34. 改造后（有htmlblockcache）的首頁測試結(jié)果： 
35.  
36. Document Path: /phpcmsv9/index.php 
37. Document Length: 41328 bytes 
38.  
39. Concurrency Level: 15 
40. Time taken for tests: 23.156 seconds 
41. Complete requests: 600 
42. Failed requests: 0 
43. Write errors: 0 
44. Total transferred: 24943200 bytes 
45. HTML transferred: 24796800 bytes 
46. Requests per second: 25.91 [#/sec] (mean) 
47. Time per request: 578.906 [ms] (mean) 
48. Time per request: 38.594 [ms] (mean, across all concurrent requests) 
49. Transfer rate: 1051.92 [Kbytes/sec] received 
50.  
51. Connection Times (ms) 
52. min mean[+/-sd] median max 
53. Connect: 0 1 5.9 0 109 
54. Processing: 94 570 177.5 547 2297 
55. Waiting: 94 563 177.7 547 2297 
56. Total: 94 571 177.3 547 2297 
57.  
58. Percentage of the requests served within a certain time (ms) 
59. 50% 547 
60. 66% 594 
61. 75% 625 
62. 80% 641 
63. 90% 703 
64. 95% 813 
65. 98% 1016 
66. 99% 1266 
67. 100% 2297 (longest request) 

而實(shí)際服務(wù)器也支持這種測試結(jié)果——由于響應(yīng)速度的提高,phpcgi的線程數(shù)也少了,CPU占用的疊加程度有所減少,負(fù)荷有所減輕.