Khi những cải thiện hiệu năng ấn tượng không quan trọng

• Tối ưu hiệu năng là một cách mạnh mẽ để hiểu các hệ thống phức tạp và cải thiện sản phẩm, nhưng ngay cả kết quả nhanh hơn 10 lần cũng có thể không thay đổi cách làm việc thực tế hay thông lượng
• Ngay cả khi giảm thời gian phản hồi truy vấn từ 5~10 phút xuống 30 giây~1 phút, nếu vẫn vượt quá ngưỡng khoảng 10 giây mà con người có thể duy trì sự chú ý khi chờ, hiệu quả cảm nhận được sẽ bị giới hạn
• Khi công việc được gói theo đơn vị nguyên như 1 hoặc 2 việc mỗi ngày, mức cải thiện 25~50% là chưa đủ; để làm được 2 việc/ngày, mỗi việc phải không quá 4 giờ tính cả thời gian di chuyển
• Trong pipeline dữ liệu, một bước chậm sẽ tạo backpressure lên phía thượng nguồn, nên dù một bước đơn lẻ nhanh hơn rất nhiều thì thông lượng đầu-cuối vẫn có thể không tăng cho đến khi mọi điểm nghẽn được giải quyết
• Cải thiện hiệu năng nên được đánh giá theo kết quả mong muốn, không phải benchmark của từng phần riêng lẻ; nếu không vượt qua các ràng buộc như duy trì chú ý, tăng số đơn vị công việc, hay thông lượng tổng thể, thì ngay cả cải thiện lớn cũng ít tạo ra hiệu quả thực tế

---

Vì sao các con số hiệu năng và kết quả thực tế lại lệch nhau

• Công việc về hiệu năng rất đáng làm vì nó giúp hệ thống vận hành hiệu quả hơn và có thể mở ra những khả năng mới cho khách hàng
• Nó cũng giúp hiểu theo kinh nghiệm thực tế cách các hệ thống phức tạp tương tác với nhau dưới quy mô và tải lớn
• Trong quá trình làm việc sát với hệ thống, người ta thường nảy ra ý tưởng để cải thiện sản phẩm và dịch vụ, và một số trong đó không liên quan trực tiếp đến tối ưu hiệu năng
• Tuy nhiên, ngay cả những thành quả đẹp mắt như “nhanh hơn 10 lần” hay “giảm 50% tài nguyên” cũng khó tạo ra thay đổi như kỳ vọng nếu không vượt qua được các ràng buộc ẩn

Vượt quá 10 giây thì sự chú ý của người dùng bị ngắt

• Có trường hợp cải thiện hiệu năng truy vấn của một cơ sở dữ liệu mới, đưa truy vấn tốn kém nhất từ 5~10 phút trên cơ sở dữ liệu cũ xuống còn 30 giây~1 phút
• Đây là mức cải thiện cỡ 10 lần, nhưng để thay đổi trải nghiệm người dùng thì vẫn cần thêm một bước cải thiện lớn nữa
• Trong nghiên cứu về tương tác người-máy, giới hạn để con người duy trì sự chú ý với toàn bộ tác vụ được xem là khoảng 10 giây
  • 0,1 giây là ngưỡng được cảm nhận như phản hồi tức thì
  • Khoảng 1 giây là ngưỡng mà luồng công việc vẫn được duy trì
  • Khoảng 10 giây là ngưỡng duy trì sự chú ý đối với toàn bộ tác vụ
  • Các phản hồi như thanh tiến trình hoặc thời gian ước tính có thể giúp duy trì sự chú ý
• Cả 30 giây lẫn 5 phút đều vượt quá 10 giây, nên người dùng sẽ kiểm tra tin nhắn, đi lấy cà phê, bắt đầu trò chuyện hoặc chuyển sang việc khác
• Nếu khi người dùng quay lại sau vài phút hoặc vài giờ mà giao diện đã tải xong, thì việc thời gian chờ thực tế là 30 giây hay 5 phút sẽ không tạo ra khác biệt lớn trong cách họ làm việc
• Cuối cùng, trong dự án đó, nhiều truy vấn đã được đưa xuống dưới 10 giây, và một số truy vấn trước đây không thể chạy vì timeout cũng trở nên khả thi
  • Không chỉ độ trễ truy vấn dữ liệu mà cả độ trễ truy vấn metadata và thời gian render trang web cũng quan trọng đối với cải thiện hiệu năng tổng thể
  • Vẫn còn khả năng đạt thêm một lần cải thiện 10 lần nữa nhờ async I/O và cải thiện tổng hợp dữ liệu, khi đó những truy vấn từng mất vài phút có thể trả về trong dưới 1 giây

Ngưỡng chuyển từ 1 việc/ngày sang 2 việc/ngày

• Trong một dự án, toàn bộ quy trình đã được rút từ vài giờ xuống còn ổn định dưới 1 giờ nhờ tự động hóa công việc thủ công, loại bỏ các bước không cần thiết, song song hóa một phần và trì hoãn một số bước có thể xử lý bất đồng bộ về sau
• Mức cải thiện vào khoảng 25~50%, nhưng toàn bộ quy trình vẫn không thay đổi vì các ràng buộc logistics
• Có thể hình dung trường hợp như thợ ống nước, thợ điện hoặc thợ mộc phải đặt lịch đến địa điểm rồi hoàn thành công việc
  • Nếu làm việc 8 giờ mỗi ngày và một công việc tại một địa điểm mất 8 giờ, thì dù tiết kiệm được 2~3 giờ cũng vẫn không đủ thời gian để di chuyển đến nơi mới và hoàn thành thêm việc mới
  • Chỉ khi mỗi công việc không quá 4 giờ tính cả thời gian di chuyển thì mới có thể hoàn thành 2 việc/ngày
• Trước khi vượt qua ngưỡng này, những cải thiện hiệu suất ở các bước trung gian sẽ không dẫn tới tăng sản lượng
• Việc tập trung vào hiệu năng cũng có thể đồng thời mang lại cải thiện về chất lượng và độ ổn định tác động trực tiếp đến trải nghiệm khách hàng
  • Ngay cả những cải thiện hiệu năng nhỏ không tạo được đột phá trong production vẫn có thể tăng tốc độ lặp trong môi trường test, từ đó đẩy nhanh phát triển tính năng và sửa lỗi

Điểm nghẽn trong pipeline có backpressure

• Nhiều hạ tầng phần mềm doanh nghiệp bao gồm pipeline dữ liệu xử lý sự kiện từ nhiều nguồn như phương tiện, thiết bị nhà máy, điện thoại di động hay giao dịch tài chính
• Các sự kiện thường được lưu vào durable log, rồi các dịch vụ hạ nguồn sẽ tiêu thụ và xử lý chúng
• Để đạt thông lượng cao ở quy mô lớn, log cần được phân vùng, còn các dịch vụ hạ nguồn sẽ dùng các kỹ thuật như xử lý theo batch, pipelining, song song hóa, cấp phát bộ nhớ hiệu quả và mở rộng động
• Điểm nghẽn trong pipeline dữ liệu khó tìm vì hành vi của các hệ thống có liên hệ với nhau
  • Một bước chậm sẽ cố ý tạo backpressure lên các bước thượng nguồn
  • Nếu có nhiều điểm nghẽn, thông lượng tổng thể sẽ không tăng cho tới khi điểm nghẽn cuối cùng cũng được loại bỏ
• Chia pipeline thành các giai đoạn và hiểu đặc tính hiệu năng cũng như giới hạn của từng giai đoạn là một thực hành kỹ thuật tốt
• Nhưng ngay cả khi cải thiện một giai đoạn đơn lẻ lên nhiều bậc độ lớn, thông lượng tổng thể vẫn có thể không thay đổi
• Trong cải thiện thông lượng, con số quan trọng không phải benchmark của từng giai đoạn mà là thông lượng đầu-cuối

Cách tiếp cận thực nghiệm để tìm điểm nghẽn

• Để hiểu động lực học và điểm nghẽn của các hệ thống như vậy, cách hữu ích là kiểm chứng theo thực nghiệm từ điểm bắt đầu của pipeline
• Ví dụ, có thể bắt đầu từ bước đọc rồi bỏ sự kiện từ distributed log
  • Nếu chỉ riêng bước này đã không đạt được thông lượng mục tiêu, thì tối ưu các bước hạ nguồn sẽ chỉ là lãng phí thời gian
• Các benchmark hạ nguồn như có thể chèn bao nhiêu dòng vào cơ sở dữ liệu mỗi giây cũng có thể quan trọng, nhưng việc phân tích nên bắt đầu từ thượng nguồn
• Mô phỏng cũng là một phương pháp có giá trị để hiểu các hệ thống phức tạp và hiệu năng
  • Marc Brooker's Simple Simulations for System Builders
  • Try again: The tools and techniques behind resilient systems

Chuẩn đánh giá cải thiện hiệu năng là kết quả mong muốn

• Công việc về hiệu năng tuy khó nhưng cũng là quá trình rèn luyện để hiểu sâu các hệ thống phức tạp và tạo ra sản phẩm tốt hơn
• Nếu cần giữ sự chú ý của con người, hệ thống phải phản hồi trong khoảng 10 giây
• Nếu bị giới hạn bởi đơn vị công việc hoàn chỉnh, thì chỉ cải thiện theo phần trăm là chưa đủ; phải đạt được mức chuyển từ 1 việc/ngày sang 2 việc/ngày
• Để tối đa hóa thông lượng của pipeline có backpressure, nhiều khi không phải giải quyết một hai điểm nghẽn mà là phải xử lý tất cả các điểm nghẽn
• Nếu không vượt qua được các ràng buộc này, thì ngay cả cải thiện hiệu năng cỡ 10 lần cũng không tạo ra kết quả mong muốn

[GN⁺]

Ý kiến trên Lobste.rs

• Nếu bạn từng cải thiện một công đoạn không ảnh hưởng đến tổng thông lượng lên hàng chục lần rồi vẫn thất vọng, thì ở đây rất đáng nhắc đến định luật Amdahl

  • Tự hỏi không biết có chỗ nào kiểu bộ sưu tập tên các định luật trong khoa học máy tính nói chung không
    Cứ liên tục nghe về các định luật mới, nhưng chúng lại đủ ngách để không được dùng thường xuyên nên rồi lại quên mất. Điều đó không có nghĩa là những định luật ấy không còn đúng hoặc không còn hữu ích như tri thức truyền đời

• Ngay từ đầu đã thấy khó hiểu vì sao lại đi tối ưu một phần chỉ chiếm một mẩu rất nhỏ trong tổng thời gian
  Không rõ là do chỉ dẫn tệ, hay vì thiếu công cụ hiệu năng. Hiếm ai cố tình làm việc gần như không có tác động; thường là có vấn đề lớn hơn ẩn bên dưới

  • Một con đường dẫn đến chuyện này thường đại khái như sau
    Bạn nhìn vào một vấn đề, thấy trong kết quả sampling có một hàm nổi bật lên, liếc qua thì có vẻ triển khai của nó có thể cải thiện khá dễ. Nhưng lúc đó bạn đang làm việc khác nên để đó, tự nhủ “để sau xử lý”
    Về sau nhớ ra cải tiến dễ đó và bắt đầu làm, nhưng đến khi sửa thật thì lại phức tạp hơn tưởng tượng, rồi tunnel vision xuất hiện và bạn muốn giải cho xong câu đố nên tốn rất nhiều thời gian
    Thực ra vấn đề hiệu năng đó chỉ là chuyện nhỏ. Trong ngữ cảnh lúc đó nó có vẻ lớn theo tỷ lệ, hoặc thời gian tuyệt đối không có nhiều ý nghĩa, hoặc hệ thống bị nghẽn bởi I/O chứ không phải CPU. Gần giống như bị nerd sniping do chính mình tạo ra
  • Ở Google từng có lần có đề xuất tối ưu một phần của pipeline, và nhiều người đã giải thích rằng phần đó chiếm dưới 0,1% tổng lượng tính toán nên lợi ích tổng thể theo định nghĩa cũng sẽ dưới 0,1%
    Dù vậy họ vẫn bỏ ngoài tai và tiến hành tối ưu; đến khi tổng cải thiện ra dưới 0,1% thì lại ngỡ ngàng. Nếu có kiến thức miền thì bằng trực giác cũng thấy đó không phải phần tốn kém, nhưng để tránh lãng phí thời gian người ta còn hỗ trợ đo cả chi phí hiệu năng thực tế
  • Có thể là họ hành động theo phỏng đoán, hoặc đã nội hóa những thực tiễn tốt nhất áp dụng mọi nơi, hoặc khái quát hóa quá mức một vấn đề có thật từng thấy trong bối cảnh hạn chế
    Cũng có thể benchmark đã gây hiểu lầm. Không phải hệ thống nào cũng dễ dàng cho thấy chi phí của mọi phương thức hay quy trình trong môi trường vận hành
    Những lời giải thích này khác nhau về mức độ, nhưng nhìn chung đều gần như là một dạng rối loạn chức năng; cái nào thì nghiêng về vấn đề cá nhân hơn, cái nào thì nghiêng về vấn đề môi trường hơn
  • Có vài lý do khả dĩ
    1. Một kỹ sư junior có năng lực đã học cách giải quyết vấn đề, nhưng chưa học được cách chọn vấn đề đáng để giải. Họ tấn công mọi điểm kém hiệu quả mình phát hiện ra, bất kể tác động đầu-cuối là gì. Nếu may mắn sẽ có người dạy; nếu không thì họ sẽ khựng lại thành một senior engineer cần PM kiểm soát rất chặt
    2. Không thể nhìn đúng hiệu năng đầu-cuối. Có suy giảm hiệu năng ở đâu đó trong hệ thống, cấp quản lý thì gây áp lực, nhưng lại không được trao quyền triển khai giám sát bài bản, nên đành đoán mò và đụng vào nhiều component với hy vọng một cái nào đó trúng. Khi chữa cháy xong thì lại quay về phát hành tính năng cho người dùng
    3. Hiện tại chưa phải vấn đề, nhưng lo rằng sắp tới sẽ thành vấn đề nên sửa trước. Nếu đủ sức ảnh hưởng hoặc có thể ép làm ngoài giờ, họ sẽ tiến hành ngay cả khi hiện tại chưa thấy hiệu quả rõ rệt. Kỹ sư giỏi cũng sẽ dùng vốn chính trị cho việc này nếu tin rằng nó sẽ quan trọng trong tương lai, còn kỹ sư kém hơn thì sẽ đốt sạch toàn bộ vốn đó
       3.1. Nếu làm ở hyperscaler, chỉ riêng việc giảm 0,1% lượng tính toán mà hoàn toàn không ai dùng nhận ra cũng có thể tạo ảnh hưởng lợi nhuận đủ để trả tiền một căn nhà ven biển
    4. Không cưỡng lại được thử thách. Họ biết rõ là thực tế sẽ chẳng thay đổi gì, nhưng đã chán chỉ làm CRUD app, và nay có cơ hội thử thứ mình đọc trên blog. Đó như một cách tự nerd snipe để bớt cảm thấy sức nặng của sự vô nghĩa
  • Trái với quan niệm phổ biến, nhiều hệ thống không chỉ được tạo thành từ vài nút thắt cổ chai
    Bản thân các thói quen lập trình phổ biến thường đã chậm trên diện rộng. Ví dụ dễ nghĩ đến là mã hướng đối tượng đầy con trỏ và cấp phát heap với mật độ rất cao thông qua allocator tổng quát. Sửa chỗ nào cũng chỉ là một mẩu nhỏ trong tổng thời gian, nên trong trường hợp xấu nhất sẽ không giải được nếu không viết lại hoàn toàn. Nếu may mắn thì có thể viết lại dần dần
    Ngay cả khi chỉ có hai nút thắt cổ chai, nếu chúng chỉ chênh nhau trong phạm vi một chữ số lần thì dù sửa hoàn hảo nút tệ nhất cũng chưa chắc mang lại cải thiện đến một bậc một chữ số. Trong nhiều trường hợp, như bài viết nói, muốn có lợi ích thật sự có ý nghĩa thì phải vượt xa hơn nhiều
    Ngoài ra máy tính gần giống một hệ thống phân tán chạy song song. Có vài CPU, GPU, đĩa, Ethernet..., và tốc độ của tiến trình bị giới hạn bởi công đoạn chậm nhất trong pipeline. Sửa công đoạn đó xong thì công đoạn chậm thứ hai lại thành giới hạn; tệ nhất là có nhiều công đoạn cùng chậm nhất nên chỉ sửa một cái cũng không đem lại lợi ích gì
    Dù vậy đây là cách diễn giải thiện chí, còn đôi khi đơn giản là người ta sa vào trò chơi tối ưu hóa, đánh mất ưu tiên, hoặc chỉ là mắc sai lầm

• Ngay cả khi người dùng không nhận ra, việc giảm thời gian tính toán của phần mềm vẫn là điều tốt
  Vì nó giúp giảm chi phí và làm cho việc mở rộng dễ hơn

  • Điều đó còn tùy vào chi phí về độ phức tạp
    Nếu cái giá để làm mã chạy nhanh hơn là đưa vào quá nhiều độ phức tạp, thì bỏ qua chuyện khả năng bảo trì sang một bên, về lâu dài nó còn tạo ra những hệ quả tiếp theo làm hại hiệu năng. Khi cấu trúc thay đổi, phần mã khi đó trở nên không còn cần thiết vẫn sẽ nằm lại đó; mà muốn hiểu hoặc gỡ nó đi thì phải hiểu trọn vẹn toàn bộ độ phức tạp
    Lý do “nó chạy nhanh hơn” không nên trở thành giấy miễn tội để bỏ qua các lo ngại về độ phức tạp hay khả năng bảo trì

• Tôi đang ở trong tình huống tương tự lúc này, và qua nhiều dự án nhỏ đang giảm một truy vấn từng mất 5 phút xuống dưới 30 giây
  Về dài hạn tôi vẫn nói với cả đội rằng như vậy là chưa đủ, nhưng rõ ràng đây là cải thiện và tác động cũng lớn
  Từ góc nhìn khách hàng, thời gian chờ đã từ mức khiến người ta nổi điên giảm xuống còn mức chỉ gây khó chịu
  Hiện tại trọng tâm không phải hiệu năng theo từng người dùng mà là hiệu năng tổng thể. Khi tối ưu hàng chục tiến trình kéo dài 5 phút, 10 phút, 30 phút, mức tranh chấp tài nguyên với các phần khác của hệ thống giảm đi đáng kể. Việc đập vào cơ sở dữ liệu suốt 10 phút là cực kỳ lâu, và rốt cuộc mọi thứ đều nhanh hơn nên ai cũng được lợi