Performance Optimization là gì? Những vấn đề xoay quanh Performance Optimization

10/09/2021

Bạn đang gặp vấn đề với performance? API của bạn có thời gian phản hồi quá lâu? Server của bạn thường xuyên quá tải? Hay hoá đơn cloud đập vào mặt bạn những con số quá kinh khủng dùng mới chỉ có một nhúm người dùng? Nếu bạn đang gặp phải những vấn đề trên, hay chỉ đơn giản bạn là một developer đang mong muốn tăng lương mà chưa biết nên lấy lý do gì, hãy đọc bài viết sau đây.

Performance Optimization là gì?

Performance Optimization là hoạt động tối ưu hiệu suất của hệ thống. Performance Optimization ở đây đối với phần mềm sẽ vẫn là làm tăng kết quả đầu ra dựa trên nguồn lực đầu vào hữu hạn. Cái bạn cần làm chính là tìm xem kết quả đầu ra là gì và nguồn lực đầu vào của bạn là gì thôi.

Performance Optimization 101

1 số kết quả đầu ra cụ thể:

  • Số lượng request có thể đáp ứng
  • Số lượng user / connection concurrent
  • Thời gian chờ của 1 request
  • Tỷ lệ request thành công

1 số nguồn lực đầu vào cụ thể:

  • Thời gian
  • CPU
  • RAM
  • Disk IO
  • Network bandwidth

Ai là người thực hiện Performance Optimization?

Không có 1 người nào hay vai trò nào luôn luôn đảm nhận công việc này. Tại sao lại như vậy?

Performance của hệ thống là 1 phạm trù rộng lớn bị ảnh hưởng bởi nhiều yếu tố cả phần cứng và phần mềm. Chính vì vậy để tối ưu được nó cũng cần sự kết hợp của rất nhiều vai trò trong công ty:

  • Đối với dev thì là tối ưu code
  • Đối với system admin thì là tối ưu phần cứng hay các cài đặt trong os
  • Đối với database admin thì là tối ưu query, tối ưu thiết kế db
  • Đối với solution architect thì là tối ưu thiết kế hệ thống
  • Đối với devops thì là tối ưu quá trình tích hợp

Hiện nay ở 1 số công ty còn xuất hiện cả 1 vai trò là Performance Engineer, tức là những kỹ sư chuyên đi ngồi tối ưu hiệu năng. Công việc của họ sẽ là phân tích, đánh giá, tìm ra vấn đề, đưa ra phương hướng giải quyết các vấn đề liên quan tới performance. Chủ yếu việc tối ưu performance sẽ được tích hợp vào công việc của nhiều vai trò khác nhau chứ sẽ không tách ra riêng hẳn như vậy.

Thường những người đóng vai trò DevOps, Sys Admin, Solution Architect là những người có khả năng tiếp cận nhiều với các bài toán về hiệu năng hơn cả. Dù vậy nhưng một cây thì làm chẳng nên non. Một người thì cũng sẽ có những hạn chế về mặt kiến thức nhất định, do vậy tối ưu performance nói chung sẽ cần phải có sự giao lưu phối kết hợp của nhiều bên.

Khi nào thì cần thực hiện Performance Optimization?

Việc tối ưu performance chỉ nên thực hiện ở cuối của quá trình phát triển, khi mọi thứ đã đi đúng quỹ đạo sẵn. Điều này cũng có phần đúng. Chính vì vậy để quyết định được "khi nào" là thời điểm phù hợp để tối ưu hiệu năng cũng sẽ là 1 câu hỏi khó trả lời. Sau khi đúc rút từ kinh nghiệm cá nhân thì mình có 1 số gợi ý như sau:

  • Luôn có performance mindset khi thiết kế và triển khai 1 giải pháp phần mềm.
  • Performance Optimization nói tới cả 1 quá trình từ khi thiết kế, triển khai tới vận hành, feedback,... Do đó hiểu biết về toàn bộ luồng của hệ thống rất quan trọng.
  • mindset về performance khác với việc thực hiện tối ưu performance ngay từ đầu. Đừng nhầm lẫn nhé. Có mindset tức là biết chỗ này có thể tối ưu được, chỗ này có thể nhanh hơn được, thiết kế chỗ này cho phép tối ưu về sau,... nhưng thực hiện thì không phải luôn và ngay mà chỉ tới khi nào cần mới thực hiện.

Performance Optimization được thực hiện ở đâu?

Hầu hết tất cả các khâu, các component của hệ thống sẽ đều có thể tối ưu được. Ví dụ draft 1 cái kế hoạch tối ưu trang web theo gu gờ:

  • Giảm số HTTP request
  • Sử dụng HTTP version 2
  • Bỏ REST sang GRPC
  • Minify css, js
  • Cache lại response
  • Denormalize Database để giảm JOIN query ...

Nhưng việc lựa chọn thực hiện tối ưu ở đâu sẽ là quá trình bạn đi tìm kiếm các vấn đề, xếp hạng vấn đềgiải quyết theo độ ưu tiên. Và đôi khi để tìm ra điểm nghẽn của hệ thống thôi cũng đã tiêu tốn của bạn không ít thời gian rồi. Hệ thống thì phức tạp mà vấn đề có khi chỉ nằm ở 1 vài cái nhỏ nhỏ nên thông thường thì chúng ta sẽ đi chệch hướng. Đôi khi chúng ta tìm kiếm sai chỗ, dẫn tới việc tối ưu không đem lại kết quả hoặc kết quả không được như mong đợi.

How can we do it?

Rất nhiều pitfall, rất nhiều sai lầm đã, đang và sẽ được tạo ra trong quá trình tối ưu này. Chung quy lại nó sẽ hay bị như này:

  • Thiếu cái nhìn tổng quan về Performance Optimization. Tối ưu performance hệ thống không chỉ là mỗi làm tăng req/s đâu.
  • Chưa có 1 lý do chính xác để thực hiện. Nên nhớ lý do sẽ quyết định bài toán, có bài toán mới biết giải theo cách nào.
  • Thiếu sự kết hợp của các bộ phận trong khâu tối ưu performance.
  • Đúng vấn đề nhưng sai thời điểm.
  • Sai cả vấn đề luôn.

Vậy để không bị mắc lại những cạm bẫy phía trên thì mình nên có 1 cách tiếp cận khoa học để thực hiện quá trình performance optimization. Các bạn có thể luyện tập đưa ra phán đoán. Trí tưởng tượng là 1 lợi thế quan trọng trong nghệ thuật phân tích điểm nghẽn hệ thống và đã giúp mình trong vô số pha cứu net. Nhưng ĐỪNG LỆ THUỘC hoặc BÁM DÍNH vào giả thuyết của bạn khi nó chưa đủ căn cứ. Luôn để mắt tìm kiếm những điều bất thường khác trong quá trình phân tích nhé.

Quy trình thực hiện

Trong cuốn System Performance - Enterprise and the Cloud của Brendan Gregg có liệt kê 9 step thực hiện việc đánh giá và tối ưu performance. Tuy nhiên mình xin tóm tắt lại bằng 1 số bước sau:

  • Chọn thang đo performance và thiết lập target về performance: Từ yêu cầu của business như có bao nhiêu user cùng truy cập các bạn phải chọn 1 cách đo lường performance (có thể là CCU, throughput, latency,...). Tiếp đến là lên kế hoạch tài nguyên (Capacity Planning). Đây là bước quan trọng nhất, làm nền cho toàn bộ các hoạt động khác như lựa chọn tối ưu cái gì, tối ưu tới mức nào,...
  • Phân tích performance tĩnh: Đánh giá performance hệ thống dựa vào việc review solution, review kiến trúc, review code,... Bước này diễn ra trong quá trình dev, yêu cầu người review (tech lead, solution architect,...) phải am hiểu về business, am hiểu về hệ thống và có khả năng đánh giá performance dựa vào trí tưởng tượng =)). Đừng cười mình, đây là kỹ năng cực kỳ quan trọng và phải tập rất nhiều, trải nghiệm rất nhiều mới có thể làm được. Trong quá trình làm cũng phải không ngừng học hỏi và cải tiến để thích ứng với các bài toán mới hơn và lớn hơn. Người làm review tốt sẽ có cơ sở rất quan trọng để đưa ra giả thiết điểm nghẽn hệ thống mà không cần hệ thống phải chạy.
  • Benchmarking: Thông thường mọi người nghĩ về performance optimization chỉ hay nghĩ tới bước này, tức là benchmarking xem app của mình có chịu được 1 cái tải gì đó không. Nhưng thực chất đây chỉ là 1 phần của quá trình tối ưu thôi. Benchmarking sẽ tái tạo 1 số điều kiện cụ thể để test xem application có đạt được performance mong muốn lúc đầu hay không.
  • Monitoring / Profiling: Performance engineer giỏi là người hiểu về monitoring cũng như cách để monitoring. Đây cũng là bước quan trọng trong suốt quá trình từ khi dev tới operation. Chúng ta thường đưa ra những giả thuyết sai lầm bởi vì thiếu thông tin của monitoring. Mình cũng thấy lạ lùng là ở rất nhiều công ty lớn, mặc dù developer đều có title Senior hết nhưng lại ít người quan tâm tới kiến thức về monitoring cũng như vận hành hệ thống. Không biết monitor ứng dụng của mình hoặc không hiểu các chỉ số là 1 thiệt thòi lớn và là rào cản khổng lồ của quá trình tối ưu performance. Monitoring còn đóng vai trò cảnh báo sớm cho các sự cố về performance có thể xảy ra.
  • Phân tích performance động khi có sự cố: Những vấn đề thực tế thì luôn khác xa những thứ ta nghĩ trong phòng lab và khi xảy ra thì chúng ta còn bị giới hạn cả thời gian để xử lý nữa, do đó đây thường là bước khó nhất và đòi hỏi nhiều skill nhất. Các bạn sẽ phải kết hợp nhiều sự hiểu biết, trí tưởng tượng và khả năng ứng biến để giải quyết được những vấn đề về performance khi phát sinh. Cái này ngoại trừ việc chuẩn bị kỹ năng debug siêu cấp và hiểu biết hệ thống thượng thừa thì mình nghĩ chỉ có thể xây đắp bằng kinh nghiệm. Cứ trải qua vài lần hệ thống quá tải rồi sẽ giác ngộ.

Cách tiếp cận

Có 2 cách tiếp cận khi đề cập tới performance analysis và sẽ ảnh hưởng tới nhiều quyết định của chúng ta sau này:

  • Phân tích workload: Đặt target về workload (tải) của hệ thống và xem application có đáp ứng được không. Ví dụ là đặt target 10.000 CCU và chạy test để theo dõi các metric sau:
    • Số lượng request vào hệ thống
    • Latency
    • Error rate Cách tiếp cận này thường được thực hiện từ hướng developer để có phương án tối ưu code.
  • Phân tích tài nguyên: Theo dõi mức độ sử dụng tài nguyên (CPU, RAM, disk, network,...) trong các trường hợp khác nhau. Ví dụ với 1 server 2 core 4GB thì sẽ chạy test để theo dõi các metric sau:
    • Throughput (req/s) tối đa
    • Utilization: mức độ sử dụng tài nguyên
    • Saturation: Điểm overload Cách tiếp cận này thường được thực hiện từ hướng system admin để có phương án quy hoạch tài nguyên, scaling,...

Trong thực tế thì mình thường kết hợp cả 2 cách tiếp cận để có 1 cái nhìn tổng quát nhất.

Tổng kết

Người ta nói trăm nghe không bằng một thấy, trăm lời nói cũng không bằng 1 hình ảnh. Mình sẽ đúc kết toàn bộ kiến thức trong bài viết này bằng sơ đồ tư duy sau:

Performance Optimization

Trên đây là những hiểu biết sơ bộ về hoạt động performance optimization và những vấn đề xoay quanh nó.

Tổng hợp 

Japan IT Works



Việc làm theo chuyên ngành

Việc làm theo ngành

Việc làm theo tỉnh thành