Cải thiện hiệu suất của nodejs với redis

Tram Ho

Introduction

  • Dự án mình đang làm có liên quan redis, nên tiện thể note lại một chút thực hành luôn.
  • Bài này mình sẽ không trình bày: Redis là gì?. Vì sao nên dùng redis.
  • Bài viết này chỉ đưa ra kết quả so sánh khi chuyển sang dùng redis làm cache hoặc thay thế các kiểu dữ liệu truyền thống (SQL và NoSQL).

Redis as cache

  • Cùng xem ví dụ nodejs app trả về thông tin sách thông qua dữ liệu của google api.

    • Không sử dụng Redis:

    • Có sử dụng redis làm cache:

  • Khi nhận được request từ client. Server với withoutRedisAsCache.js sẽ call api bên thứ ba (ở đây là google) và trả về cho người dùng. Server với withRedisAsCache.js sẽ check redis trước không có mới gọi api google ( và sẽ được cập nhật vào redis cho lần gọi sau).

  • Để chạy phía server ngoài khởi tạo 2 file như trên. Mình cài đặt 1 số thứ:

    • npm init -y khởi tạo project
    • Cài đặt các module cần thiết: npm i express axios response-time redis
    • Khởi chạy phía server side với node withoutRedisAsCache.js hoặc node withRedisAsCache.js.
  • Giờ cùng xem thời gian phản hồi của mỗi api như nào. Với cùng một truy vấn tới server. Ở đây mình muốn check thời gian server phản hồi. Nếu bạn muốn xem full response thì bỏ option --head là được:

  • Khi không có redis thời gian server xử lý 748.695ms:

  • Khi có redis làm cache thời gian xử lý 151.236ms:

Redis as DB

  • Một ví dụ thứ hai, một số trường hợp thay vì lưu vào db truyền thống SQL hay noSQL chúng ta có thể sử dụng redis thay thế.

  • Sử dụng mongodb:

  • Ở đây mình tạo 1 collection User với một document đơn giản {name: Asterisk, lastLogin: string} với lastLogin là time theo mili giây.

  • Cài đặt gói mongoose: npm i mongoose.

  • Chạy server: node mongoDB.js.

  • Check response từ phía server:

  • Check Header xem thời gian phản hồi:

  • Như vậy với một bản ghi, đã được index, thời gian cỡ khoảng 2.821ms

  • Nếu cùng mục đích sử dụng lưu lastLogin nhưng lần này mình sẽ lưu trong redis thì sao:

  • Sử dụng redis:

    • Test thử response từ phía server:

    • Check header xem thời gian phản hồi 0.384ms:

Conclusion

  • Phần trên mình demo 2 ví dụ thay đổi thời gian phản hồi server tới client:
    • Khi dùng redis làm cache thời gian giảm: 748.695ms -> 151.236ms.
    • Khi dùng redis làm db thời gian giảm: 2.821ms -> 0.384ms.
  • Hai thay đổi về thời gian trên chỉ mang tính tương đối vì mỗi lần chạy thời gian có thay đổi đôi chút. Nhưng dù sao cũng thấy được tỉ lệ thay đổi khá rõ dệt về mặt thời gian phản hồi.
  • Khi các kết quả trả về client ít thay đổi chúng ta có thể xem xét việc dùng Redis làm cache và cập nhật lại khi có thay đổi ví dụ: thông tin người dùng, hoặc trong ví dụ trên thông tin một quyển sách: tác giả, năm phát hành …
  • Khi API ưu tiên tính thời gian thực phản hồi nhanh như trong ví dụ 2 chúng ta có cũng thế xem xét lưu một số thông tin trong redis thay vì db thông thường. Dù mỗi loại DB vẫn có điểm mạnh riêng chúng ta cần cân nhắc khi chọn lựa

Bonus Redis command exec on:

  • String:

    • GET: lấy ra giá trị của key (get value of key) trả về nil nếu key không tồn tại và error nếu gía trị lưu trong key không phải string. GET chỉ handle giá trị là string.
    • SET: gán giá trị (kiểu string ) cho một key. Nếu key đã có giá trị nó sẽ bị ghi đè ( không quan tâm kiểu trước đó là gì). Các options:
      • EX giây: thời gian bị hết hạn theo giây.
      • PX mili giây: thời gian bị hết hạn theo mili giây.
      • NX: Chỉ xét khi key chưa chứa giá trị.
      • XX: Chỉ xét nếu key đã chưa giá trị.
    • Do SET có các options như trên nên các câu lệnh như sau có thể bị bỏ trong tương lại: SETEX, SETNX, PSETEX.
    • INCR: Tăng số đang được lưu trong key lên một. Nếu key không có giá trị nó được gán về 0 và tăng lên 1 ( tức = 1).Trả về lỗi nếu giá trị lưu trong key không phải là string hoặc string không chuyển thành số được. Phép cộng 1 giới hạn bởi 64 bit signed integers.
    • DECR: Tương tự INCR nhưng thằng này trừ 1.
  • List:

    • To be con tì niu: sẽ update thêm mấy lệnh nữa trong redis.

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo