公司的網站平常都很快,做直播的時候,網站速度也沒變慢,
但只要主持人說開始商品搶購,網站就會非常慢,按個鈕會沒反應,好幾秒後網頁才會動,
因此覺得可能是sql方面的問題,想查是哪個部份被lock了,
用jmeter模擬一秒同時80人進網頁,連續執行10次,
同時用下列語法查詢sql中被lock的物件:
SELECT request_session_id AS spid,
resource_type AS rt,
resource_databASe_id AS rdb,
(CASE resource_type
WHEN 'OBJECT' then object_name(resource_ASsociated_entity_id)
WHEN 'DATABASE' then 'DB'
ELSE
(SELECT object_name(object_id) FROM sys.partitions
WHERE hobt_id = resource_ASsociated_entity_id) END) AS objname,
resource_description AS rd,
request_mode AS rm,
request_status AS rs,*
FROM sys.dm_tran_locks
where request_mode in ('x','ix')
但查出的7、80筆紀錄大部份都是:
欄位「objname」物件名稱都是nulL,我還是不知道是哪邊出問題,
請問我這樣子查是ok的嗎?還是我的做法不對?該怎麼找出網站卡住的問題呢??
懷疑是資料庫處理過慢,有許多方式可以改善:
這個用微服務和消息隊列來進行優化和程式提升
使用redis來記錄庫存, 有人下單就扣和判斷庫存
扣除成功之後, 把資料寫到消息隊列Message queue去進行後續處理
這樣就完全可以避開了請求太多的問題了
謝謝,我先來了解一下redis是什麼東西。
給點意見, 可以從這幾個方面去思考和改進代碼:
如果是讀取資料緩慢就考慮用Redis做中間緩存, 不然所有用戶同時間擠著進來絕對把你的數據庫打趴了
流量大需要有load balancer去分擔流量, K8S就有很好的調度功能了, 當流量大的時候pods會auto scaling, 然後內部也有實現load balancer功能, 當然简单的话, 就用nginx也能做到load balancer
程式內解藕 loosing couple, 不要一堆邏輯擠著一個function裡面執行, 可以學下消息隊列message queue把業務拆分
做這類型網站上線之前做好是做好壓測QPS等等
參考以下觀念圖
參考以下架構圖
如果有美國時間的話
就研究一下尚硅谷 尚品匯