距離上次服務(wù)器將圖片轉(zhuǎn)義至oss服務(wù)器提交加載速度已經(jīng)有一段時(shí)日了

對(duì)于圖片轉(zhuǎn)移至oss服務(wù)器優(yōu)化前后的結(jié)果可以查看我之前編寫的文章點(diǎn)擊查看

如今隨著商戶數(shù)的增多，數(shù)據(jù)的增多，服務(wù)器的性能再一次達(dá)到了頂峰，并且由于是點(diǎn)餐系統(tǒng)的緣故訂單的，中午12點(diǎn)點(diǎn)餐人數(shù)對(duì)服務(wù)器的架構(gòu)進(jìn)行了一次瘋狂的考驗(yàn)經(jīng)過將歷史訂單表和分為今日訂單和歷史訂單表，數(shù)據(jù)庫(kù)和CPU得到了初步緩解，但是通過后臺(tái)查看過多的數(shù)據(jù)和中午大并發(fā)的查詢還是導(dǎo)致CPU和內(nèi)存還是居高不下，于是有了本文，我們最終決定將中午常用的菜單，菜單列表，商戶信息等不經(jīng)常更新的信息存儲(chǔ)值Redis緩存看是否對(duì)服務(wù)器能起到緩解作用

按照慣例查看前后性能圖

首先我們?cè)谖覀兊臏y(cè)試1核2G的服務(wù)器上做壓力測(cè)試

首先是走數(shù)據(jù)庫(kù)的

我們可以看到在并發(fā)為20左右時(shí)候已經(jīng)大面積異常，響應(yīng)緩慢，接口返回?cái)?shù)據(jù)已經(jīng)相當(dāng)緩慢了

最后我們可以看到走數(shù)據(jù)庫(kù)的話在數(shù)據(jù)庫(kù)數(shù)據(jù)量比較大的情況下，會(huì)導(dǎo)致高并發(fā)查詢緩慢，并且導(dǎo)致接口響應(yīng)特別緩慢的情況在100并發(fā)逐級(jí)遞增的測(cè)試下，并發(fā)數(shù)越高，響應(yīng)越緩慢，就想中午點(diǎn)餐時(shí)候一樣，大量的人同時(shí)掃描二維碼卻因?yàn)轫憫?yīng)緩慢數(shù)據(jù)一致取不到頁(yè)面轉(zhuǎn)圈這是很影響體驗(yàn)的

下面的就是使用Redis的接口的性能測(cè)試

可以看到在使用了Redis緩存后，接口響應(yīng)數(shù)據(jù)完爆每次都讀取數(shù)據(jù)庫(kù)的接口，成功率也從1.59%的成功率提升至了99.55%成功率

?

最后來一張服務(wù)器的Redis圖

下一期著重講解.net MVC項(xiàng)目如何添加Redis緩存

?

?

?

總結(jié)

以上是生活随笔為你收集整理的.net Redis缓存优化提高加载速度和服务器性能(一)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。