Tối giản việc đọc tin nổi bật, comment chất lượng nhiều reaction trên voz cho các fen bận rộn.

VozFen.com: [thắc mắc] Backend của 1 app check trạng thái Covid gần 100 triệu active users, làm sao để nó không lag

@Buonnguqua6
#1
Ưng 9

[thắc mắc] Backend của 1 app check trạng thái Covid gần 100 triệu active users, làm sao để nó không lag

@naiveryan 07/2009
#3
Ưng 6
Vàng quan điểm
Chủ đề hay đó.

Daily active user k tới 100tr đâu, tầm 30tr thôi. Thì CCU sẽ là 3tr.

Cơ bản thì mọi ngã đường đều dẫn tới db, nghẽn ở db cả thôi. 100tr bản ghi thì ko có gì lớn, nếu đọc ko thì vô tư, ghi mới chết. Mà app covid ghi chẳng bao nhiêu, nên tôi nghĩ replica mạnh là đủ chơi rồi.

Edit: Thằng dev front-end cũng quan trọng, call API vô tội vạ, ko biết caching rồi tự bóp chết server cũng là điều ko hiếm.

@minhneo 08/2007
#13
Ưng 6
Vàng quan điểm
1. Database 1 write, n read (n tùy nhu cầu). Bonus nếu dùng database hiệu con voi https://swarm64.com/
2. n api, phân tải theo khu vực, nhà mạng, dãi AS,...
3. app caching
4. Redis database caching dùng case của instagram đã áp dụng để lấy thông tin ảnh (google là ra, nhớ k nhầm cao điểm 300tr query vẫn chạy ào ào)
Write, update thông tin ngày chắc không quá 1tr thì đâu có lớn.

Kiến thức hạn hẹp, ae đừng gạch nha.

@Fire Of Heart
#26
Ưng 5
hệ thống này thì các anh dẹp vụ AWS đi là vừa
các quan ko cho xài cloud nc ngoài đâu )

Thêm cái đó vô requirement đi là vừa.

Chưa kể user ở VN là chính thì đẩy qua Sing làm gì :-/

Về cơ bản cứ caching đầy đủ từng lớp là đã giảm tải dc 1 đống rồi. Mà đếch hiểu sao tụi nó ko làm :-/
dựng 3 con cache 16GB thôi là đủ xài rồi, vì cái này có cái mịa gì đâu, 1 cái uid + status (chích/ko chích/chích 1-2 mũi).
Chưa kể cache trong device nữa thì

@greans
#31
Ưng 4
Con lạy mẹ
Read mà delay vài phút dân nó tế
Giữa Sài Gòn nắng chang chang đứng ngoài cửa quán cafe chờ quét QR code vài phút mới được vào nó lại chả quan hệ với mẹ app liên tục
Không phải là quét QR chờ phút mà là cần thời gian để system update data. Chẳng lẽ anh chích ngừa xong anh phi ngay ra quán luôn.

Theo CAP theorem thì anh phải chấp nhận đánh đổi consistency thôi, không có hệ thống nào có thể đáp ứng cả 3 yếu tố được.

Mấy anh # đầu mô tả hợp lý rồi đấy. Cũng không phải gì cao siêu bài toán read điển hình. quan trọng là tầng cache thôi.

Cloud vẫn có thể làm được, như thằng AWS có hỗ trợ private cloud đấy, nó xách giải pháp của nó áp lên datacenter của chính phủ luôn.

@naiveryan 07/2009
#45
Ưng 5
yếu thì ko dám nói, nhưng mà trình chắc chắn là còi
vì trình độ IT của Việt Nam ko kém, và mấy vấn đề này trên thế giới người ta đã giải quyết được hết rồi
đừng nói là vài trăm ngàn request/giây
đến cả vài tỷ request/giây cũng ko phải là vấn đề
do đó ko thể đổi lỗi app chạy chậm lag là do nhiều người dùng được
Ghê, tỷ request/giây, cho xin cái ví dụ tỷ request/giây tại vn đi bạn?

Đừng có bảo là google search nhé.

@qkhanhpro1 06/2012
#101
Ưng 15
Vàng quan điểm
Góp vui 1 xíu với anh em
Mình giới hạn bài toán lại 1 case cụ thể như sau
Peak 50 Triệu người lao động đi làm mỗi buổi sáng, mỗi người query theo ID (quét QR) 5 lần trên đường đi làm, thời gian di chuyển trên đường coi như dồn hết vào 8AM-8:30AM
Vậy trong thời gian 30 phút đó, peak concurrent request là 50M * 5 / 30(phút) / 60(giây) ~ 140K request per sec. Xin tạm ước lượng thế dù mình tin thực tế avg cao điểm có lẽ chỉ = 20% con số trên

Vậy bài toán đặt ra: Thử viết server handle được 140K query per sec với chi phí tối thiểu

Mình thử spawn 1 ít server cho BE - DB giá rẻ
Tổng cấu hình server : 16G Mem, 4 Core - Ubuntu - 80 USD / Mo
Tổng cấu hình DB: 4G Mem, 4 Core - Postgres - 60USD / Mo

Tiến hành và kết quả
1/ Cố gắng gửi nhiều request hết mức có thể với mục tiêu 0% internal server error hoặc response time > 30s. Duy trì tải 15 phút
2/ Mình triển khai .NET Core trên Linux, kết nối đến Postgres, Tổng số record trong DB là 40 Triệu

Back-end



DB CPU


DB Queue depth


Kết quả
total processed event: 747500
total elapsed time: 465897

Tương ứng với số lambda invocation : 1000 / phút (Mình dùng lambda để stress test, mỗi lambda mở 100 http request đến server)


Concurrent request: 1600 requests per second. Mình không đẩy cao hơn được nữa dù CPU vẫn còn rảnh rất nhiều do DB Disk không tải nổi (Nhìn DB Queue Depth ở trên)
1 Internal server error
AVG server resp time: < 1000 ms


Anh em có thể query thử
http://18.136.61.75:5000/vaxx
http://18.136.61.75:5000/vaxx/{id} ( từ 1 đến 40 triệu )
Edit: Đã tắt các endpoint do hết tiền
Không cache không cloudflare

@Fire Of Heart
#128
Ưng 5
Câu chuyện đơn giản thế này:
Anh thiết kế 1 hệ thống, anh biết 100mil user xài rồi đó.
Để tối ưu, anh dựng cache ở 3 miền.
Giờ anh báo với sếp cần cbi để mua server, hay thuê gì đó. Sếp hỏi anh cần bao nhiêu để còn chuẩn bị mua.
Sau 1 hồi suy nghĩ anh bảo cần 1 con CPU xxx, Ram 16 gb, v.v….
Sếp hỏi anh vậy đủ ko? Tại sao là 16 GB mà ko phải 32, 64 v.v….
Các a trả lời kiểu gì? Em thích? Số đẹp? Hay hôm nay đề về?

Tôi lựa redis vì: persist xuống disk. Tự build LRU hay xài memcache thì ko có cái này, scale cũng kém hơn. (Memcache bản mới chắc có persist thì phải, ko nhớ), redis scale cũng tiện hơn lại theo mô hình master slave.

Giờ muốn tính thì phải ước lượng cache bao nhiêu item, size bao nhiêu trên redis.

Chính xác hơn thì insert thử 100k record, tôi lười nên tính vài cái cho vui.

Estimate số lượng thì tuỳ.
Miền bắc/nam đông dân thì cho size lớn, miền trung thưa thì size nhỏ hơn. Cái này tôi chưa tính, nhưng tạm cho 2 đầu Bắc/nam mỗi nơi 40tr dân. Miền trung cho 20 tr đi.
Kích thước thì 40mil/10gb theo đó mà lựa cho phù hợp.

Còn tôi ignore 1 ng, ko phải là ng ta ý kiến khác tôi mà ignore. Như thread này Tôi vẫn tranh luận với các bạn khác bt.

Tôi ignore khi thái độ, ngôn từ của họ với tôi làm tôi khó chịu. Đơn giản mà. Lên đây để giải trí.
Ng ta làm mình khó chịu thì lơ đi. Việc quái gì phải cãi nhau cho mệt.
Thanh niên freedom kia, vô là công kích mình. Ok tiễn. Ko tiếp