Tôi hiểu luồng được điều khiển mà Apache sử dụng: mọi kết nối sẽ mở ra một chuỗi và khi phản hồi được gửi, luồng được đóng, giải phóng tài nguyên cho các luồng khác).Nginx xử lý các yêu cầu HTTP như thế nào?
Nhưng tôi không nhận được thiết kế hướng sự kiện mà Nginx sử dụng. Tôi đã đọc một số vấn đề cơ bản về thiết kế hướng sự kiện .. nhưng tôi không hiểu cách này được nginx sử dụng để xử lý các yêu cầu web.
Tôi có thể đọc và hiểu cách Nginx xử lý các kết nối theo cách điều khiển sự kiện để tôi hiểu tại sao nó tốt hơn, thay vì chấp nhận thiết kế dựa trên sự kiện đó tốt hơn thiết kế hướng luồng.
nhưng nếu một luồng có thể phục vụ hàng chục nghìn người dùng, tại sao không sử dụng nhiều luồng để phân phối nhiều hơn? hoặc tôi hiểu sai. –
Vì lò phản ứng phải thực hiện các thao tác không an toàn như đọc từ ổ cắm. Đa luồng (một nhóm cố định các luồng công nhân, ví dụ một cho mỗi CPU) có thể với mẫu Proactor, hoạt động hơi khác một chút - ví dụ hệ điều hành đặt dữ liệu đọc vào bộ đệm cho bạn (bạn chỉ định bộ đệm khi bắt đầu không đồng bộ hoạt động). Nhưng proactor có những nhược điểm riêng của nó - nó phải dự trữ nhiều bộ nhớ hơn cho bộ đệm; nó cũng chậm hơn trên Linux khi chỉ sử dụng một CPU duy nhất. – Onestone
"nếu một chủ đề có thể phục vụ hàng chục ngàn người dùng, tại sao không sử dụng nhiều chủ đề" --- luồng là một kludge từng được phát minh để cắt giảm các quy trình tốn kém, với mức độ phức tạp tăng lên. toàn bộ điểm làm I/O không đồng bộ là để bạn có thể xử lý nhiều khách hàng trong một quá trình đơn lẻ và lấy luồng ra khỏi cửa sổ. Tôi khá chắc chắn bạn sẽ không thấy bất kỳ lợi ích hiệu suất đáng giá của luồng trong lĩnh vực I/O không đồng bộ. – flow