iT邦幫忙

2021 iThome 鐵人賽

DAY 8
2
Mobile Development

如何用下班時間開發App經營副業系列 第 8

服務反應每慢一秒,轉換率就會掉 12%

很多時候在討論使用者友善,其實最簡單粗暴,也最有感的改善之一就是讓操作動作變快,也就是讓用戶更快得到他要的東西。畢竟只要操作上有卡頓,用戶馬上就會分心。
之前看 Google Startup School 的 SEO 課程中也有說

網頁 loading 每慢一秒,轉換率就會掉 12%

我們在優化我們 app 的體驗時,很常做的一件事就是去看現在效能瓶頸在哪,然後去改善。
比如之前有個很容易成為效能瓶頸的情景是「隨機配對」功能。這應該是遊戲很常出現的功能,但我們不能說是完全隨機,因為我們還有保證配對兩邊是以前沒有配對過的。
當用戶按下隨機配對,我們要從 Queue 裡面找出「還沒跟他配過對」的人給他,所以最壞情況就是每次用戶按一次這個鈕,都要回去查找一遍目前所有存在的配對來決定。關於這個動作的改善,我們有過三種版本:

  1. MongoDB
  2. Redis
  3. Cache + Redis

初始版本:單純用mongoDB

最一開始,很單純的,就是每次從現有的對話 collection 裡查找,頂多把 userID 設為 index。
但是資料量變大,時間跨度變大時,mongoDB 的話,一定會有一部份舊資料會放在 disk,導致每次查找都會出現 disk I/O ,因為這是一個很高頻的操作,所以每次都有 disk 的操作會非常沒效率。於是我們自然開始思考要怎麼改善。

導入 in-memory DB: Redis

號稱最快的資料庫 Redis,因為是完全在memory上處理,剛好符合我們的需求,所以我們就加了一個 Redis的 node,紀錄所有配對過的帳號,專門用來解決這個問題。 Redis 用一個獨立的 node 而不是跟後端程式放在一起,原因是,我們當時的後端已經有好幾個 node。如果把 Redis 部署在其中一個 node,就會導致這些後端的 instance 產生 dependency。更不可能部署在所有的 node,這樣就無法有一個單一的正確的 snapshot。
Redis 的好處是保障所有查找都是 in-memory ,解決了 mongo 的 disk I/O 的負擔。但是量大之後,還是會受限於 Redis 所在 node 的規格,此時可以選擇就直接花錢提升 CPU 解決,或是再從架構上改善。

導入 30 分鐘的 cache

小團隊節儉就是美德,改善規格看似每個月不貴,但一提升就是會變成每個月的固定支出,不可不慎呀。所以我們當然是選擇從架構上改善。
導入 Redis 之後,還是會有問題的情況是,重度用戶會在短時間內按好幾次配對,所以只要尖峰時段有很多重度用戶,就會塞車。所以我們在進入 Redis 查找之前,另外加上一個 30 分鐘過期的 cache,紀錄最近30分鐘內的配對,只要在裡面找到,就不用再去 redis 找。針對重度用戶的使用情境,這個方法可以省掉很多 redis 的 query。 30 分鐘的 cache 也不會造成記憶體太大負擔。

結論

一開始為了解決 mongo 的負擔,在查詢過往配對上我們改用 redis 來實作。後來因為 redis 也不夠用,我們為了降低資料庫查找頻率,加入了 30 分鐘的 cache。目前流程就是會先看有沒有 cache,沒有的話就是去 Redis 查找。這個方法開始用之後,就幾乎沒聽過有人抱怨這個功能的速度了。
讓操作變快變順暢,是很直觀的用戶體驗優化,但是實際上要做的事通常並不像是改介面那麼直觀。

最新文章會分享在臉書:https://www.facebook.com/gigi.wuwu/
歡迎留言討論


上一篇
沒想太多就用了 MongoDB 的結果 (下)
下一篇
只要有 UGC,就是要花費大把青春跟 Spam 對抗
系列文
如何用下班時間開發App經營副業30

尚未有邦友留言

立即登入留言