Some Anti-Methodologies against Performance Analysis and Tuning


Bài này sẽ mô tả một số phương pháp cho vấn đề phân tích và điều chỉnh hiệu năng làm việc của hệ thống (system performance analysis and tuning), bao gồm cả những cách tiếp cận sai lầm, anti-methodology, nhưng lại phổ biến trong thực tế.

1. Streetlight Anti-Method

Người phân tích perf bắt đầu bằng cách chọn một công cụ quan sát (observability tool) quen thuộc, dễ dàng tìm thấy trên Internet, hoặc đột nhiên nhớ ra tool nào đó rồi chạy chúng để xem có gì bất thường hiện ra ngay trước mắt hay không. Cách này thuộc dạng hên xui và có thể bỏ sót các chi tiết là mấu chốt của vấn đề.

Khi đụng tới bước điều chỉnh perf thì người này thường đi theo lối thử sai (trial-and-error), thiết lập các giá trị khác nhau cho bất cứ tham số nào quen thuộc và được phép cho tới khi vấn đề được giải quyết.

Nếu tool được chọn không giúp phát hiện hoặc tuning không liên quan tới bản chất của vấn đề thì cách này bộc lộ khuyết điểm là làm tốn thời gian nhưng vẫn được áp dụng chỉ bởi vì họ quen dùng tool này nhất, hiểu được tuning kia nhất. Sở dĩ được gọi streetlight vì nó bắt nguồn từ câu chuyện ngụ ngôn sau:

“Vào một đêm nọ, người cảnh sát viên bắt gặp một gã xỉn rượu đang loay hoay dưới cột đèn đường nên bèn tới hỏi xem gã đang kiếm thứ gì vậy. Gã nói là đang tìm lại chiếc chìa khóa bị thất lạc. Người cảnh sát này liền phụ gã một tay nhưng cũng kiếm không ra nên hỏi tiếp rằng có chắc là gã đánh rơi nó ở đây, dưới chân cột đèn đường này hay không. Gã trả lời: “Cũng không chắc, nhưng đây là nơi sáng nhất đó anh!”

Lệnh top là một ví dụ về streetlight mà người dùng Unix thường nghía qua khi tìm hiểu vấn đề perf đang gặp phải vì nhiều lúc họ chọn nó không phải vì nó sẽ chỉ ra các thông tin liên quan có giá trị mà là họ không biết tới các tool khác.

2. Random Change Anti-Method

Người dùng cách này sẽ đoán đại căn nguyên và thay đổi loạn xà ngầu cho tới khi vấn đề biến mất. Sẽ có một chỉ số để giúp xác định xem perf có được cải thiện sau mỗi lần tuning hay không như latency, throughput, IOPS.

Rõ ràng làm như thế rất là mất thời gian và kèm theo rủi ro. Ngoài ra thì tuning cuối cùng có thể chỉ là tạm thời mà thôi. Ví dụ như một thay đổi được áp dụng đã giúp cải thiện perf cho application do nó “workaround” một lỗi của database hoặc OS, mà lỗi này không lâu sau đã được sửa luôn. Vì vậy mà application vẫn tồn tại tuning không còn tác dụng đó nữa nên dẫn tới sau này không còn ai hiểu được chính xác ý nghĩa của tuning đó là gì.

3. Blame-Someone-Else Anti-Method

Cách sai lầm này đi theo trình tự sau:
1- Tìm ra một bộ phận (hệ thống hoặc môi trường) mà tôi không có trách nhiệm quản lý.
2- Cho là vấn đề nằm ở bộ phận đó.
3- Chuyển rắc rối của vấn đề tới đội đang chịu trách nhiệm cho bộ phận đó.
4- Khi thấy rằng nghi án của mình là sai, quay trở lại bước 1.

Kiểu như:
“Vấn đề chắc tại network rồi. Cậu thử phối kiểm với đội network xem có phải là họ đã “drop packet” hay làm thứ gì đó sai trái không nhé?”

Bởi vậy, thay vì tập trung tìm hiểu vấn đề cho ra lẽ thì người ứng dụng phương pháp này đã vội đẩy trách nhiệm sang cho người khác. Điều này thực sự không tốt vì sẽ làm lãng phí nguồn lực của các bên chưa biết có liên quan hay không. Nhưng an ủi là thường vì thiếu dữ liệu dẫn tới giả định sai chứ không phải người ta cố ý buông lơi như thế (j/k :)).

-mt.

Ref.
http://queue.acm.org/detail.cfm?id=2413037