本來(lái)我一直不知道怎么來(lái)更好地優(yōu)化網(wǎng)頁(yè)的性能，然后最近做python和php同類網(wǎng)頁(yè)渲染速度比較時(shí)，意外地發(fā)現(xiàn)一個(gè)很簡(jiǎn)單很白癡但是 我一直沒(méi)發(fā)現(xiàn)的好方法（不得不BS我自己）：直接像某些php應(yīng)用比如Discuz論壇那樣，在生成的網(wǎng)頁(yè)中打印出“本頁(yè)面生成時(shí)間多少多少秒”，然后在 不停地訪問(wèn)網(wǎng)頁(yè)測(cè)試時(shí)，很直觀地就能發(fā)現(xiàn)什么操作會(huì)導(dǎo)致瓶頸，怎樣來(lái)解決瓶頸了。

于是我發(fā)現(xiàn)SimpleCD在 生成首頁(yè)時(shí)，意外地竟然需要0.2秒左右，真真不能忍：對(duì)比Discuz論壇首頁(yè)平均生成才0.02秒，而Discuz論壇的首頁(yè)頁(yè)面無(wú)疑比 SimpleCD的主頁(yè)要復(fù)雜不少；這讓我情何以堪啊，因?yàn)檫@必然不是Python語(yǔ)言導(dǎo)致的差距，只能說(shuō)是我完全沒(méi)做優(yōu)化而Discuz程序優(yōu)化得很好 的后果。

其實(shí)不用分析也能知道肯定是數(shù)據(jù)庫(kù)在拖累，SimpleCD在生成首頁(yè)時(shí)需要在sqlite的三個(gè)數(shù)據(jù)庫(kù)中進(jìn)行42多次查詢，是歷史原因?qū)е碌臉O其低效的一個(gè)設(shè)計(jì)；但是這40多次查詢中，其實(shí)大部分是非?？斓牟樵儯屑?xì)分析一下就有兩個(gè)是性能大戶，其他都不慢。

第一個(gè)大戶就是：獲取數(shù)據(jù)個(gè)數(shù)
 

SELECT count(*) FROM verycd

這個(gè)操作每次都要花不少時(shí)間，這是因?yàn)槊看螖?shù)據(jù)庫(kù)都要鎖住然后遍歷一遍主鍵統(tǒng)計(jì)個(gè)數(shù)的緣故，數(shù)據(jù)量越大耗時(shí)就越大，耗時(shí)為O(N)，N為數(shù)據(jù)庫(kù)大?。粚?shí)際 上解決這個(gè)問(wèn)題非常容易，只要隨便在哪存一個(gè)當(dāng)前數(shù)據(jù)的個(gè)數(shù)，只有在增刪數(shù)據(jù)的時(shí)候改動(dòng)就行了，這樣時(shí)間就是O(1)的了

第二個(gè)大戶就是：獲取最新更新的20個(gè)數(shù)據(jù)列表
 

SELECT verycdid,title,brief,updtime FROM verycd   ORDER BY updtime DESC LIMIT 20;

因?yàn)樵趗pdtime上面做了索引，所以其實(shí)真正查詢時(shí)間也就是搜索索引的時(shí)間而已。然則為什么這個(gè)操作會(huì)慢呢？因?yàn)槲业臄?shù)據(jù)是按照publish time插入的，按update time進(jìn)行顯示的話就肯定需要在至少20個(gè)不同的地方做I/O，這么一來(lái)就慢了。解決的方法就是讓它在一個(gè)地方做I/O。也就是，除非數(shù)據(jù)庫(kù)加入新數(shù)據(jù) /改變?cè)袛?shù)據(jù)，否則把這條語(yǔ)句的返回結(jié)果緩存起來(lái)。這么一來(lái)又快了20倍：）

接下來(lái)的是20條小case：取得發(fā)布人和點(diǎn)擊數(shù)信息
 

SELECT owner FROM LOCK WHERE id=XXXX; SELECT hits FROM stat WHERE id=XXXX;

這里為什么沒(méi)用sql的join語(yǔ)句來(lái)省點(diǎn)事呢？因?yàn)榧軜?gòu)原因這些數(shù)據(jù)放在不同的數(shù)據(jù)庫(kù)里，stat是點(diǎn)擊率一類的數(shù)據(jù)庫(kù)，因?yàn)樾枰l繁的插入所以用 mysql存儲(chǔ)；而lock和verycd是需要大量select操作的數(shù)據(jù)庫(kù)，因?yàn)閙ysql悲劇的索引使用情況和分頁(yè)效率而存放在了sqlite3數(shù) 據(jù)庫(kù)，所以無(wú)法join -.-

總之這也不是問(wèn)題，跟剛才的解決方法一樣，統(tǒng)統(tǒng)緩存