国产片侵犯亲女视频播放_亚洲精品二区_在线免费国产视频_欧美精品一区二区三区在线_少妇久久久_在线观看av不卡

腳本之家,腳本語言編程技術及教程分享平臺!
分類導航

Python|VBS|Ruby|Lua|perl|VBA|Golang|PowerShell|Erlang|autoit|Dos|bat|

服務器之家 - 腳本之家 - Python - Python中用memcached來減少數據庫查詢次數的教程

Python中用memcached來減少數據庫查詢次數的教程

2020-05-31 10:46腳本之家 Python

這篇文章主要介紹了Python中用memcached來減少數據庫查詢次數的教程,memcached是一種分布式的內存緩存工具,使用后可以減少對硬盤的I/O次數,需要的朋友可以參考下

本來我一直不知道怎么來更好地優化網頁的性能,然后最近做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結構,最常使用的就是兩個函數了:

  1.     第一個就是set(key,value,timeout),這個很簡單就是把key映射到value,timeout指的是什么時候這個映射失效
  2.     第二個就是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了)

延伸 · 閱讀

精彩推薦
Weibo Article 1 Weibo Article 2 Weibo Article 3 Weibo Article 4 Weibo Article 5 Weibo Article 6 Weibo Article 7 Weibo Article 8 Weibo Article 9 Weibo Article 10 Weibo Article 11 Weibo Article 12 Weibo Article 13 Weibo Article 14 Weibo Article 15 Weibo Article 16 Weibo Article 17 Weibo Article 18 Weibo Article 19 Weibo Article 20 Weibo Article 21 Weibo Article 22 Weibo Article 23 Weibo Article 24 Weibo Article 25 Weibo Article 26 Weibo Article 27 Weibo Article 28 Weibo Article 29 Weibo Article 30 Weibo Article 31 Weibo Article 32 Weibo Article 33 Weibo Article 34 Weibo Article 35 Weibo Article 36 Weibo Article 37 Weibo Article 38 Weibo Article 39 Weibo Article 40
主站蜘蛛池模板: 亚洲午夜精品久久久久久高潮 | 欧美成人精品一区二区男人看 | 国产精品精品久久久 | av中文在线 | 亚洲狠狠爱| 久久免费精品一区二区三区 | 国产一区日韩欧美 | 色片在线观看 | 亚洲男人的天堂视频 | 色婷婷综合久久久中文字幕 | 欧美成人一区二免费视频软件 | 成人av免费 | 欧美全黄 | 亚洲小视频| 韩日一区| 久久av网站 | a∨色狠狠一区二区三区 | 综合av在线 | 自拍偷拍在线视频 | 久久se精品一区精品二区 | 国产精品久久久久久久久久久免费看 | 国产精品欧美一区二区三区不卡 | 成人精品福利视频 | 精品久久久久久久 | 一区二区国产在线观看 | 最新一级毛片 | 中国黄色一级视频 | 亚洲视频中文字幕 | 日日撸 | 一区二区三区高清不卡 | 一区二区三区视频在线观看 | 久久免费精品视频 | 日本精品一区二区三区在线观看视频 | 亚洲欧美在线观看 | 中文字幕欧美激情 | 国产精品99久久久久久动医院 | 激情久久综合网 | 国产乱码一区二区三区 | 97久久精品 | 99久久久成人国产精品 | 亚洲欧美在线播放 |