Hồi tháng 5 đã có bài giới thiệu về nội dung này rồi, ấy thế mà tôi lười quá thể đáng, nay mới tiếp tục tìm hiểu và viết. Tài liệu chính thì tôi đang xài cuốn này “System performance enterprise and the cloud” - Đọc cũng khá là tâm đắc nên ae nào rảnh đọc tìm hiểu cùng tôi. Tác giả là “System Performance Engineer” ở netflix nên khả năng ae không phải lăn tăn.

Bài này chủ yếu kiểu "Phương pháp luận" - Ý là chỉ focus vào nhận thức của ae mà thôi

intro

System performance cần cho ai?

Cần cho tất cả mọi người. Focus vào system administrators, support staff, application developers, database administrators, and web administrators Liệt kê thế thôi chứ ý là cho mn (nói rồi)

Pre-require?

Điều đầu tiên trước khi bắt tay vào system performance người thực hiện cần phải thực sự hiểu về hệ thống đích. Bắt đầu là phần cứng sau là phần mềm đặc biệt là flow data (data path) của ứng dụng. Tốt nhất là nên mô tả lại bằng một diagram cho trực quan. Nói thì các ae cứ cười chứ điều này khá là hiển nhiên rồi, chỉ khi thực sự hiểu hệ thống ta mới có thể tối ưu nó.

Ông tác giả có cái “framework cho ae” dĩ nhiên sẽ cần phải áp chi tiết vào hệ thống của ae,

Stack

System performance hiệu quả nhất khi nào?

Anw nếu là System Architecture tôi sẽ chú ý vào điều này (rất tiếc tôi ko phải SA nhưng tôi thích tôi làm thôi) .System performance cần được thực hiện một cách liên tục và có tính xoay vòng. Về cơ bản cần được liên tục thực hiện trong suốt quá trình build nên ứng dụng.

  • Bắt đầu tối ưu từ lúc design flow data, khi implement thì tối ưu từng dòng code, từng cấu trúc, từng câu truy vấn. To hơn là từng module
  • Sau đó là tối ưu khi build (option build), tích hợp các module.
  • Đến khi deploy lên production cần tối ưu platform: netowrk, phần cứng, os, Backend service (điều chỉnh các option sao cho phù hợp với product)
  • Liên tục monitor sâu ứng dụng phát hiện sớm các điểm bất thường, không ổn để liên tục lặp lại quá trình fix bug cải thiện hiệu năng (performance)

Tôi thấy họ viết eng ở đây khá là khó hiểu ae có thể tham khảo =))

Step

Điểm nhìn của system performance

Để cover & có cái nhìn toàn diện phủ kín các case - cần chia nhỏ ra các category. Tôi thấy ông tác giả chia ra Work load analystResource Analyst. Mô tả nó bằng cái hình sau

Step

Dễ nhận thấy rằng workload analyst là trách nhiệm của ông Sofware Developer còn Resource Analyst là trách nhiệm của ông Sysadmin. Tuy nhiên thực tế thấy rằng khi lỗi xảy ra ông nào cũng bảo “Không phải tôi” =)) - Suy nghĩ sai cmn lầm trầm trọng. Lỗi có thể xảy ra ở bất cứ đâu nên khi có sự cố xảy ra cần lắm 1 tâm lý bình tĩnh, trách nhiệm và sụ cộng tác của đôi bên trong khi fix bug vì our system - our love.

Thách thức (Kể khổ)

  • Performance là chủ quan (có thể trắng, đen hoặc trắng pha đen). Lấy ví dụ là với thông tin “The average disk I/O response time is 1 ms” với hệ thống A có thể là nhanh nhưng với hệ thống B là siêu rùa, không chấp nhận được. Tóm lại là nó tùy vào yêu cầu hệ thống không phải là con số cụ thể.

  • Các hệ thống lớn phức tạp (kể khổ) - khó bug. Issue có thể xuất hiện ở nhiều điểm -> kết quả không triệt để. Fix bug ở đây nhưng lại vô tình gây bug chỗ khác (đm).

Latency,

Latency - Ý là thời gian “bị delay” để thực hiện 1 thứ gì đó. Đây là thông số quan trọng cần chú ý/ cố tìm tìm khi đánh giá/monitor gì đó.

Chốt “latency is a useful metric”

Anw, đó là các nội dung kiểu “Phương pháp luận” cho ai dấn thân vào tìm hiểu System Performance.

End part 1,