本來我一直不知道怎么來更好地優化網頁的性能,然后最近做python和php同類網頁渲染速度比較時,意外地發現一個很簡單很白癡但是 我一直沒發現的好方法(不得不BS我自己):直接像某些php應用比如Discuz論壇那樣,在生成的網頁中打印出“本頁面生成時間多少多少秒”,然后在 不停地訪問網頁測試時,很直觀地就能發現什么操作會導致瓶頸,怎樣來解決瓶頸了。
于是我發現SimpleCD在 生成首頁時,意外地竟然需要0.2秒左右,真真不能忍:對比Discuz論壇首頁平均生成才0.02秒,而Discuz論壇的首頁頁面無疑比 SimpleCD的主頁要復雜不少;這讓我情何以堪啊,因為這必然不是Python語言導致的差距,只能說是我完全沒做優化而Discuz程序優化得很好 的后果。
其實不用分析也能知道肯定是數據庫在拖累,SimpleCD在生成首頁時需要在sqlite的三個數據庫中進行42多次查詢,是歷史原因導致的極其低效的一個設計;但是這40多次查詢中,其實大部分是非常快的查詢,仔細分析一下就有兩個是性能大戶,其他都不慢。
第一個大戶就是:獲取數據個數
1
|
SELECT count (*) FROM verycd |
這個操作每次都要花不少時間,這是因為每次數據庫都要鎖住然后遍歷一遍主鍵統計個數的緣故,數據量越大耗時就越大,耗時為O(N),N為數據庫大小;實際 上解決這個問題非常容易,只要隨便在哪存一個當前數據的個數,只有在增刪數據的時候改動就行了,這樣時間就是O(1)的了
第二個大戶就是:獲取最新更新的20個數據列表
1
2
3
|
SELECT verycdid,title,brief,updtime FROM verycd ORDER BY updtime DESC LIMIT 20; |
因為在updtime上面做了索引,所以其實真正查詢時間也就是搜索索引的時間而已。然則為什么這個操作會慢呢?因為我的數據是按照publish time插入的,按update time進行顯示的話就肯定需要在至少20個不同的地方做I/O,這么一來就慢了。解決的方法就是讓它在一個地方做I/O。也就是,除非數據庫加入新數據 /改變原有數據,否則把這條語句的返回結果緩存起來。這么一來又快了20倍:)
接下來的是20條小case:取得發布人和點擊數信息
1
2
3
|
SELECT owner FROM LOCK WHERE id=XXXX; SELECT hits FROM stat WHERE id=XXXX; |
這里為什么沒用sql的join語句來省點事呢?因為架構原因這些數據放在不同的數據庫里,stat是點擊率一類的數據庫,因為需要頻繁的插入所以用 mysql存儲;而lock和verycd是需要大量select操作的數據庫,因為mysql悲劇的索引使用情況和分頁效率而存放在了sqlite3數 據庫,所以無法join -.-
總之這也不是問題,跟剛才的解決方法一樣,統統緩存
所以縱觀我這個例子,優化網頁性能可以一言以蔽之,緩存數據庫查詢,即可。我相信大部分網頁應用都是這樣:)
終于輪到memcached了,既然打算緩存,用文件做緩存的話還是有磁盤I/O,不如直接緩存到內存里面,內存I/O可就快多了。于是memcached顧名思義就是這么個東東。
memcached是很強大的工具,因為它可以支持分布式的共享內存緩存,大站都用它,對小站點來說,只要出得起內存,這也是好東西;首頁所需要的內存緩沖區大小估計不會超過10K,更何況我現在也是內存土豪了,還在乎這個?
配置運行:因為是單機沒啥好配的,改改內存和端口就行了
1
2
3
|
vi /etc/memcached .conf /etc/init .d /memcached restart |
在python的網頁應用中使用之
1
2
3
|
import memcache mc = memcache.Client([ '127.0.0.1:11211' ], debug = 0 ) |
memcache其實就是一個map結構,最常使用的就是兩個函數了:
- 第一個就是set(key,value,timeout),這個很簡單就是把key映射到value,timeout指的是什么時候這個映射失效
- 第二個就是get(key)函數,返回key所指向的value
于是對一個正常的sql查詢可以這么干
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
sql = 'select count(*) from verycd' c = sqlite3.connect( 'verycd.db' ).cursor() # 原來的處理方式 c.execute(sql) count = c.fetchone()[ 0 ] # 現在的處理方式 from hashlib import md5 key = md5(sql) count = mc.get(key) if not count: c.execute(sql) count = c.fetchone()[ 0 ] mc. set (key,count, 60 * 5 ) #存5分鐘 |
其中md5是為了讓key分布更均勻,其他代碼很直觀我就不解釋了。
優化過語句1和語句2后,首頁的平均生成時間已經降低到0.02秒,和discuz一個量級了;再經過語句3的優化,最終結果是首頁生成時間降低到了 0.006秒左右,經過memcached寥寥幾行代碼的優化,性能提高了3300%。終于可以挺直腰板來看Discuz了)