Vai trò của Nginx đối với web app

Khi viết web app bằng các ngôn ngữ script như Python, Ruby, JavaScript (NodeJS) và triển khai lên server, ta hay được khuyên cho chạy web app của ta đằng sau Nginx, tức là Nginx sẽ đứng chắn giữa web app của ta và người truy cập. Mọi truy vấn web từ người dùng sẽ đi đến Nginx, và Nginx đóng vai trò của một reverse proxy, chuyển tiếp truy vấn đến web app.

Vậy Nginx làm công việc gì, ích lợi ra sao?

Giờ ta ví dụ với web app được viết bằng Django.

Giả sử ta không có Nginx, và để các request từ phía trình duyệt người dùng gửi đến thẳng web app. Ta biết rằng, phần lớn thời gian từ lúc trình duyệt gửi request đến lúc nhận được response là dành cho việc truyền tải nội dung, thời gian xử lý để sinh ra response chỉ chiếm một phần nhỏ. Giả sử web app chỉ phục vụ một request một lần, thời gian phục vụ mỗi request là 1s (bao gồm thời gian xử lý sinh ra nội dung 100ms và còn lại là thời gian truyền tải), thì trong 1 phút, web app chỉ phục vụ được 60 request. Chưa kể, khi ấy web app cũng phải phục vụ request những file tĩnh, như các file ảnh, JavaScript, CSS, vốn không phải là mục đích chính của web app. Web app là để sinh ra nội dung động. Nếu phải phục vụ cả các file tĩnh này thì số lượng phục vụ những request để nhận nội dung HTML bị rút gọn lại rất ít. Khi ta mở một trang web, thường request nội dung HTML là 1, trong khi request file tĩnh kể trên có thể là 10, và thường file tĩnh nặng hơn nội dung HTML động nên thời gian truyền tải cũng lớn hơn, có thể tới 2s. Như vậy, với cách cài đặt như trên, 1 phút web app chỉ phục vụ 3 - 6 khách. Nếu có 1 vài khách ở xa, hay đường truyền chậm, vì khách này cũng ngốn mất thời gian của web app. Số lượng phục vụ lại càng giảm.

Khi ta sử dụng Nginx chắn giữa, thì đối tượng mà web app trao đổi cùng là Nginx chứ không phải người dùng đâu đó ngoài Internet. Mà vì Nginx và web app cùng chạy trên một máy, nên thời gian truyền tải gần như bằng 0. Thời gian để web app phục vụ một request được rút ngắn từ 1s xuống còn 100ms. Việc gửi/nhận nội dung giữa server và máy của người dùng do Nginx đảm nhận. Do Nginx có khả năng phục vụ đồng thời nhiều request, theo kiểu bất đồng bộ (vẫn có thể tiếp nhận một request từ một khách khác, trong khi đang bận với khách này), nên hầu như không có sự xếp hàng chờ lượt, không có thời gian "thất nghiệp" cho web app. Trong suốt 1 phút, web app có thể hoạt động "kín chỗ", nên có thể phục vụ tới 60 request. Khi sử dụng Nginx, ta cũng đẩy hết việc phục vụ file tĩnh cho Nginx, nên 60 request ở trên hoàn toàn là phục vụ nội dung HTML, nên có thể nói, 1 phút web app của ta phục vụ được tới 60 khách, so với 3 - 6 khách của cách cài đặt chạy-một-mình ở trên.

Đấy là web app của ta chỉ phục vụ một request một lúc. Nếu ta cấu hình web app để phục vụ đồng thời nhiều request, chẳng hạn dùng Gunicorn để chạy web Django, con số 60 ở trên còn có thể nhân lên nữa.