41: Giao tiếp giữa các tiến trình(*) ảnh hưởng đến thời gian phản hồi của ứng dụng

Thời gian phản hồi là một yếu tố quan trọng ảnh hưởng đến khả năng sử dụng phần mềm. Một điều gây khó chịu trong quá trình sử dụng là chờ đợi phản hồi từ hệ thống, đặc biệt là khi sự tương tác với phần mềm liên quan cần lặp đi lặp lại. Chúng tôi cảm thấy phần mềm đang tốn nhiều thời gian và nó gây ảnh hưởng đến năng suất. Tuy vậy, nguyên nhân của thời gian phản hồi kém là không có đủ sự quan tâm từ nhà phát triển, đặc biệt là trong các ứng dụng hiện đại. Nhiều tài liệu về quản lý hiệu suất vẫn tập trung vào cầu trúc dữ liệu và thuật toán, các vấn đề này có thể khác đi trong một số trường hợp nhưng ít có khả năng chi phối hiệu suất trong các ứng dụng doanh nghiệp đa tầng hiện đại (multi-tier enterprise applications).

Khi hiệu suất là một vấn đề trong nhiều ứng dụng, kinh nghiệm của tôi là việc kiểm tra các cấu trúc dữ liệu và thuật toán không thích hợp để tìm kiếm giải pháp. Thời gian phản hồi phụ thuộc nhiều vào số lượng các giao tiếp từ xa giữa các tiền trình (IPC) để hồi đáp lại một yêu cầu. Mỗi giao tiếp từ xa giữa các tiến trình ảnh hưởng một phần nhỏ vào tổng thời gian phản hồi nhưng sẽ trở nên nghiêm trọng khi các quá trình này phát sinh liên tục.

Một ví dụ điển hình là Ripple Loading trong phần mềm có sử dụng object-relational mapping (kỹ thuật chuyển đổi dữ liệu giữa các hệ thống). Ripple Loading mô tả việc thực hiện liên tục các lệnh gọi cơ sở dữ liệu để chọn các dữ liệu cần thiết qua đó xây dựng một biểu đồ cho các đối tượng (như Lazy Load trong cuốn sách “Martin Fowler’s Patterns of Enterprise Application Architecture”).

Khi cơ sở dữ liệu của khách hàng là một máy chủ ứng dụng trung cấp để hiển thị một trang web, các yêu cầu từ cơ sở dữ liệu được thực hiện liên tục trong luồng đơn. Độ trễ của mỗi quá trình đơn lẻ sẽ ảnh hưởng đến thời gian phản hồi tổng thể. Ngay cả khi các câu lệnh từ cơ sở dữ liệu chỉ mất 10ms, một trang yêu cầu 1000 câu lệnh (điều này không thật sự phổ biến) sẽ hiển thị mất khoảng 10 giây. Một số ví dụ khác như dịch vụ web, yêu cầu HTTP từ trình duyệt web, dẫn các đối tượng tương phản (distributed object invocation), yêu cầu trả lời tin nhắn và tương tác bằng lưới dữ liệu (data-grid interaction) qua các giao thức mạng tùy chỉnh. Cần càng nhiều IPC từ xa để trả lời một yêu cầu, thời gian phản hồi sẽ càng nhiều. Có một số cách hay để giảm số lượng IPC từ xa với mỗi yêu cầu. Một cách trong số đó là áp dụng phân tích cú pháp, tối ưu hóa giao diện giúp thay đổi dữ liệu chính xác cho mục đích hạn chế tối đa các giao tiếp. Một cách khác là song song hóa (parallelize) các IPC ở bất cứ vị trí nào có thể, nhờ đó thời gian phản hồi tổng thể chủ yếu được tác động bởi IPC có tốc độ xử lí yêu cầu nhanh nhất. Cách thứ ba là lưu trữ kết quả của các IPC trước đó, để có thể tránh được sự ảnh đến cache cục bộ qua tính năng của các IPC.

Khi bạn đang thiết kế một ứng dụng, hãy chú ý đến số lượng IPC trong mỗi yêu cầu. Khi phân tích các ứng dụng có hiệu suất kém, tôi thường nhận ra rằng tỉ lệ giữa các IPC và những yêu cầu là 1/1000. Việc giảm tỉ lệ này, cho dù bằng cách lưu vào cache hoặc song song hóa hay một kỹ thuật nào khác, đều sẽ mang lại nhiều lợi ích hơn so với việc thay đổi cấu trúc dữ liệu hoặc điều chỉnh thuật toán sắp xếp.

(*) Inter-Process Communication (IPC)