thắc mắc Hỏi về cách tối ưu performance cho các hệ thống api/db/backend

Hi các bác.

Có bác nào chuyên về Backend có thể giải thích overview sơ giúp mình về các cách thức tối ưu performance cho các hệ thống api/db/backend không nhỉ? Chia được ra các tầng tối ưu luôn thì càng tốt, với tầng code middleware api thì làm thế nào, tầng db thì làm thế nào, tầng cloud/cicd thì làm thế nào?

Xét ví dụ là 1 hệ thống discount code, giả sử ta có 1 table DiscountCode chứa hàng triệu unique code khuyến mãi được distribute cho hàng triệu user call api redeem xài chẳng hạn, chạy qua hàng loạt chương trình khuyến mãi thì cái table này sẽ trở nên rất nặng, có thể lên tới hàng trăm triệu record làm chậm performance đi nhiều, vậy làm sao có thể tối ưu được việc này nhỉ?

Cám ơn các bác.

Để tối ưu được thì bác cần có công cụ để "đo" xem vấn đề đang nằm ở đâu, bottle neck ở đâu. Mà để làm cái này thì cần có công cụ để APM ngay từ ban đầu, chứ về sau khi hệ thống phức tạp sẽ khá là khó và mất thời gian. Đơn giản nhất thì thêm log ở các bước để đánh giá thôi.
Về ví dụ bảng lớn thì có các công cụ để đặt index, sharding, hay partition 1 bảng to để tối ưu truy vấn.

Nói đơn giản thế này nhé. Hệ thống nào muốn tăng performance hay tăng tải thì cũng nhắm vào các thứ dưới đây:

1. Phân tán, chia nhỏ nó ra API, database…
2. Caching, cái gì cảm thấy cache được thì cache.
3. Asynchronous hoặc Parallel, tác vụ nào gọi nhiều tác vụ con mà làm độc lập dc thì nên làm song song.
4. Thay đổi protocol ví dụ REST chậm thì đổi sang gPRC…
5. Đổi công nghệ, tech stack, framework… ví dụ chạy Java chậm thì xài C++…
6. Nâng cấp phần cứng, network…

Chém gió thế thôi chứ tôi cũng toàn làm CRUD

via theNEXTvoz for iPhone

đừng vẽ bài toán nữa.

ngu kiến của mình là case của thớt thì tùy bussiness logic để làm, có thể dùng Partitioning trong sql(mysql) để thực hiện.

Đọc quyển này nhé: Systems Performance: Enterprise and the Cloud
https://www.amazon.com/gp/aw/d/B08J5QZPNC/ref=dp_ob_neva_mobile

Sách đề cập đến đường lối chung để giải quyết những bài toán về performance: monitor như thế nào, cách dự đoán Hotspot,...
Và sau đó là đi vào trường hợp cụ thể. Ví dụ nếu là CPU thì nên tracing những cái gì. nếu là do RAM, file system, block device, network sẽ cũng có những phương pháp riêng của nó.

Phương pháp đơn giản nhất áp dụng được cho nhiều trường hợp mà mình học được trong sách này là USE: Usage / Saturation / Error. Tức là với mỗi tài nguyên trong hệ thống, tính 3 thông số này, nếu có giá trị bất thường thì khả năng cao nó là nguyên nhân chính. Tài nguyên có thể là CPU, RAM, PCIE, bus (phần cứng), TCP SYN queue, pid (phần mềm). Nói chung là phải hiểu hệ thống để xác định được, chỉ biết mỗi code với DB không thì chưa đủ.

Giới thiệu về tác giả: hiện là performance engineer ở Netflix. Là tác giả của l2arc cache trong zfs. Tác giả của bpftrace và một loạt tool trong bộ bcc.

Sent from Xiaomi M2007J20CG using vozFApp

Trước chỗ cũ em làm 1 bảng hơn 3 tỉ record mysql 5.x vẫn chạy phà phà . Để tối ưu thì có vài thứ :

• Tăng cấu hình, tăng ram cái này nên nghĩ đến đầu tiên trước khi đụng cái khác
• Chia lại db theo khu vực ví dụ asian thì vào db ở asia kiểu scale chiều ngang
• Table mà lớn quá thì tách table làm nhỏ ra. VD id 1->10^6 thì table_1, id > 10^6 thì table_2
• Đánh index cho table nhưng chú ý đừng có đánh lung tung không thì vứt lên es scale bn thì bỏ thêm tiền bấy nhiêu đỡ phải nghĩ
• API : cache, queue, chạy xử lý song song

Em chém thế thôi

Sent from vsmart Live via nextVOZ

em làm backend, e trả lời là ko có câu trả lời cho 1 bài toán chung chung đâu.

nó tùy từng project cụ thể. và có người chuyên làm db, chuyên network, vận hành - monitor, nói chung là chỗ nào chậm thì xử chỗ đó. bên em cả chục thằng vận hành hệ thống to, mà em ko biết bọn nó làm gì, thi thoảng có lỗi nó báo cho mà xử thì em có issue để làm.

hệ thống bé, mới phát triển thì đào đâu ra chuyên gia db mà tối ưu. nên cứ từ từ làm dần

em viết code thì e sẽ phải viết log đầy đủ, thi thoảng có issue mà ko có log thì trace rất vất vả. và mất thời gian code thêm chỗ write log, đợi nó lỗi, rồi fix (vài tuần từ lúc biết có lỗi, nhưng ko biết chính xác lỗi gì)

Như mấy bác trên có nói đó, index + cache, hoặc prepare sẵn data bằng cron job.
Thường là phải đo xem chậm do đâu:

Lấy ví dụ:
1. Mình đo được chậm do câu query thì xem mình có query quá nhiều field dư thừa hay là query lồng nhiều không.
2. Mình thấy query tới database nhanh (40-50ms) thì xem thời gian con api gọi tới database có nhanh ko? (Thường con api đặt ở sing và con db đặt ở mỹ thì cũng có thể gây chậm => đặt 2 con gần nhau là ổn)


Ví dụ thôi chứ còn tùy nhiều trường hợp nữa

Love U So Much said:

nó tùy từng project cụ thể. và có người chuyên làm db, chuyên network, vận hành - monitor, nói chung là chỗ nào chậm thì xử chỗ đó. bên em cả chục thằng vận hành hệ thống to, mà em ko biết bọn nó làm gì, thi thoảng có lỗi nó báo cho mà xử thì em có issue để làm.

Click to expand...

Kiểu này không ổn đâu.
Ai cũng chỉ biết một mảng của mình thì không thể debug xử lý vấn đề có sự ảnh hưởng qua lại của nhiều mảng.

Lấy ví dụ Netflix, xem cách mà họ tối ưu bandwidth video từ 100 Gbps -> 200 Gbps trên 1 server: https://papers.freebsd.org/2019/Eur..._optimizations_network_stack.files/slides.pdf

Ý tưởng chung là giảm copy qua lại nhiều nhất có thể. Nên họ dùng kTLS để encrypt TLS ngay tại kernel thay vì trên userspace. Ngoài ra vì trên server CPU thì tốc độ truy cập bộ nhớ không đồng nhất (NUMA), sẽ có những vùng bộ nhớ mà CPU #0 nhanh nhưng CPU #1 lại chậm vì phải thêm một lần copy qua bus như infinity fabric. Vậy nên lại phải phân chia hợp lý để dữ liệu luôn ưu tiên đặt ở cùng NUMA domain với CPU sẽ xử lý nó. Kết quả là phải update cả network stack của OS lẫn phần mềm phía backend.

Có thể thấy là liên quan đến đủ các mảng: storage, infra, backend, network, ... Nếu ai cũng chỉ biết việc của mình thì khó mà nhận ra được vấn đề. Kiểu như bên code thấy chậm, profiling code không thấy có vấn đề gì thì cứ kêu bên infra nâng cấp server, bên storage đổi disk sang nvme hết, bên network tăng bandwidth là xong hết trách nhiệm. Còn không được nữa thì kệ coi như giới hạn hạn rồi.

À, nếu có hứng thú thì link dưới có hướng dẫn về tự học system design, tổng hợp nhiều article mà các công ty lớn chia sẻ cách họ scale hệ thống của mình:
https://github.com/donnemartin/system-design-primer#real-world-architectures

Chạy server cấp độ lượng tử

Yên trí, thiết lập được sever lượng tử rồi thì các vấn đề khác là kiến bọ thôi.

discount code thì lúc nào chả có start date với end date. Đánh index cho nó là xong rồi search trong vòng 1 năm trở lại, auto nhanh.
nếu code có thể tồn tại trong nhiều năm thì thêm 1 flag nữa rồi đánh index cho flag đó là xong.
nếu discount code chỉ dùng đc 1 lần thì dùng xong xóa luôn đi cho khỏe.
nếu code dùng lại đc cho nhiều user thì khi search ra được thì cache nó vào redis, thằng đến sau vào redis mà đọc.

Cách phổ biến nhất khi tối ưu hệ thống là tìm ra nguyên nhân, sau đó dùng não để giải quyết.
Nếu dùng não mà k giải quyết đc thì nói với sếp là e xin nghỉ việc, tại cơ bản k có bài toán nào về performance mà k giải quyết đc cả, vấn đề là cái giá là gì thôi.

hoctrokha said:

Cách phổ biến nhất khi tối ưu hệ thống là tìm ra nguyên nhân, sau đó dùng não để giải quyết.
Nếu dùng não mà k giải quyết đc thì nói với sếp là e xin nghỉ việc, tại cơ bản k có bài toán nào về performance mà k giải quyết đc cả, vấn đề là cái giá là gì thôi.

Click to expand...

chuẩn rồi, có tiền chơi sang đưa hết vấn đề devops cho bọn cloud, thì chỉ còn cần giải quyết business thôi, còn vừa tiền ít vừa hít l thơm thì chịu