Drupal7 非常強(qiáng)大，其強(qiáng)大核心之一是entity field模式，比如node/taxonomy term/ user 都是一種entity, 并且支持field模式，也就是用戶可以隨意的添加新的field給node/taxonomy term/user；

強(qiáng)大的背后是性能的擔(dān)憂；加入node有10個(gè)field,那么就對(duì)應(yīng)10個(gè)表來裝載field數(shù)據(jù)，而不是一個(gè)列，這就導(dǎo)致了至少10個(gè)join 去查詢一個(gè)node. 這對(duì)數(shù)據(jù)庫(kù)的性能影響是巨大，甚至是致命的；試想，如果一個(gè)頁(yè)面有10個(gè)block, 每個(gè)block包含10個(gè)node, 每個(gè)node有10個(gè)field, 那么查詢表的次數(shù)就是10次（使用entity_load_multiple），join的次數(shù)是100次;

我們幾乎沒有直接的辦法解決這個(gè)問題，畢竟這就是Drupal.

在這里我們提供一個(gè)小的性能優(yōu)化辦法，即使用drupal_static函數(shù)，這個(gè)優(yōu)化方法是PHP級(jí)別的，需要了解基本的PHP知識(shí)。

這個(gè)函數(shù)可以緩存函數(shù)執(zhí)行結(jié)果，保證在函數(shù)執(zhí)行退出后，結(jié)果存在內(nèi)存中，但是又不同于memcache，它在一個(gè)請(qǐng)求結(jié)束后就自動(dòng)釋放。

這里舉個(gè)例子：

現(xiàn)在有這樣子的需求，頁(yè)面上有2個(gè)block: last_news block, last_comment block，內(nèi)容要求是last_comment 需要10條，首先取last_news 的comment, 如果不足，則按照時(shí)間先后順序取出除了和last_news comment 匹配的項(xiàng)；

分析下，last_news block保護(hù)了last_news 數(shù)據(jù)，在last_comment 也需要這個(gè)數(shù)據(jù)，假設(shè)有方法叫: news_last_news_data() 返回這個(gè)last_news,

函數(shù)原型:

則需要調(diào)用2次，那么數(shù)據(jù)庫(kù)也需要查詢2次，相對(duì)的JOIN問題也會(huì)凸顯，在并發(fā)量情況下，比如20，那么數(shù)據(jù)庫(kù)來說就有20次查詢，壓力還是有點(diǎn)的怕，在1G內(nèi)存下VPS應(yīng)該是撐不住這個(gè)并發(fā)了；

怎么辦？我們要減少數(shù)據(jù)庫(kù)的請(qǐng)求，分析，我們看到news_last_news_data()不需要參數(shù)，功能也就是查詢而已，我們斷定每次調(diào)用返回的結(jié)果都是一樣。那么我們有沒有辦法緩存查詢結(jié)果？

有！ drupal_static來了.

看下面?zhèn)未a:

分析如下：

第一行，我調(diào)用了drupal_static()方法，第一個(gè)參數(shù)是一個(gè)key, key是唯一鍵，這里使用魔法常量__FUNCTION__表示, 代表著使用方法名作為key, 第二個(gè)參數(shù)是默認(rèn)值，當(dāng)緩存不存在的時(shí)候使用一個(gè)空的數(shù)組替代

第二行，我加了一個(gè)判斷，如果$last_news緩存已經(jīng)存在，則不執(zhí)行查詢，這樣就減少了這個(gè)查詢的一半的壓力，運(yùn)行一下，速度是不是很塊！

后面的代碼你應(yīng)該懂了吧！

此處還要注意：在php5.1.13有一個(gè)BUG, 也是我使用過程中遇到的，意思是當(dāng)在匿名方法里面使用use關(guān)鍵字調(diào)用匿名方法上層的變量，且這個(gè)變量是來自drupal_static的返回值，那么匿名方法執(zhí)行完后，會(huì)修改上層的變量的引用，也就是在后面引用到這個(gè)變量，那么這個(gè)變量以及不是drupal_static的返回值，所以緩存會(huì)失效。這個(gè)BUG說的很復(fù)雜，遇到后就看看是否使用了匿名方法吧。

最新評(píng)論