Mẹo để tối đa hóa yêu cầu Nginx / giây?


15

Tôi đang xây dựng gói phân tích và yêu cầu dự án nêu rõ rằng tôi cần hỗ trợ 1 tỷ lượt truy cập mỗi ngày. Đúng, "tỷ". Nói cách khác, không dưới 12.000 lượt truy cập mỗi giây được duy trì và tốt nhất là một số phòng sẽ bùng nổ. Tôi biết tôi sẽ cần nhiều máy chủ cho việc này, nhưng tôi đang cố gắng đạt được hiệu suất tối đa từ mỗi nút trước khi "ném thêm phần cứng vào nó".

Ngay bây giờ, tôi đã hoàn thành phần theo dõi lượt truy cập và được tối ưu hóa tốt. Tôi gần như chỉ lưu các yêu cầu vào Redis (để xử lý sau với Hadoop). Ứng dụng này là Python / Django với gunicorn cho cổng.

Máy chủ Rackspace Ubuntu 10.04 2GB của tôi (không phải máy sản xuất) có thể phục vụ khoảng 1200 tệp tĩnh mỗi giây (được đánh dấu bằng Apache AB với một tài sản tĩnh duy nhất). Để so sánh, nếu tôi trao đổi liên kết tệp tĩnh với liên kết theo dõi của mình, tôi vẫn nhận được khoảng 600 yêu cầu mỗi giây - tôi nghĩ điều này có nghĩa là trình theo dõi của tôi được tối ưu hóa tốt, bởi vì nó chỉ chậm hơn 2 lần so với phục vụ cùng một tài sản tĩnh nhiều lần.

Tuy nhiên, khi tôi điểm chuẩn với hàng triệu lượt truy cập, tôi nhận thấy một vài điều -

  1. Không sử dụng đĩa - điều này được mong đợi, vì tôi đã tắt tất cả nhật ký Nginx và mã tùy chỉnh của tôi không làm gì ngoài việc lưu chi tiết yêu cầu vào Redis.
  2. Sử dụng bộ nhớ không liên tục - Có lẽ do quản lý bộ nhớ của Redis, việc sử dụng bộ nhớ của tôi sẽ dần dần tăng lên và sau đó giảm xuống, nhưng nó chưa bao giờ là nút cổ chai của tôi.
  3. Tải hệ thống dao động trong khoảng 2-4, hệ thống vẫn phản hồi trong cả các điểm chuẩn nặng nhất của tôi và tôi vẫn có thể xem thủ công http://mysite.com/tracking/pixel với độ trễ có thể nhìn thấy trong khi máy chủ (khác) của tôi thực hiện 600 yêu cầu mỗi thứ hai.
  4. Nếu tôi chạy thử nghiệm ngắn, giả sử 50.000 lượt truy cập (mất khoảng 2m), tôi nhận được 600 yêu cầu ổn định, đáng tin cậy mỗi giây. Nếu tôi chạy thử nghiệm dài hơn (đã thử tới 3,5m cho đến nay), r / s của tôi giảm xuống còn khoảng 250.

Những câu hỏi của tôi --

a. Có vẻ như tôi đang max máy chủ này chưa? Là tập tin tĩnh nginx hiệu suất 1.200 / s có thể so sánh với những gì người khác đã trải nghiệm?

b. Có điều chỉnh nginx phổ biến cho các ứng dụng khối lượng lớn như vậy? Tôi có các luồng công nhân được đặt thành 64 và các luồng công nhân gunicorn được đặt thành 8, nhưng điều chỉnh các giá trị này dường như không giúp ích hay làm hại tôi nhiều.

c. Có bất kỳ cài đặt cấp độ linux nào có thể giới hạn các kết nối đến của tôi không?

d. Điều gì có thể khiến hiệu suất của tôi giảm xuống 250r / giây trong các bài kiểm tra dài hạn? Một lần nữa, bộ nhớ không được tiết kiệm tối đa trong các thử nghiệm này và việc sử dụng ổ cứng là không.

Cảm ơn trước, tất cả :)

EDIT Đây là cấu hình nginx của tôi - http://pastie.org/1450749 - nó chủ yếu là vani, với chất béo rõ ràng được cắt bỏ.


Bạn đang thực hiện nhiều câu hỏi trong một bài đăng, hãy xem xét sửa đổi. Tôi chỉ đưa ra nhận xét và không trả lời, vì tôi không thể trả lời tất cả các phần. Tôi giả sử bạn đã xem xét hiệu suất của Python / Django - nó không lý tưởng cho tốc độ cực cao. Về 1200 req / s, âm thanh rất thấp đối với những gì tôi giả sử là phản hồi gif 1px hoặc HTTP 204. Xem fx simonhf.wordpress.com/2010/10/02/nginx-versus-sxe-hello-world (24k req / s, chạy trên localhost, nhưng chỉ sử dụng 1 nginx worker.)
Jesper M

Goldmine bình luận, cảm ơn bạn rất nhiều. Tôi sẽ đọc qua bài viết và trở lại với những phát hiện của tôi; cảm ơn con trỏ "nhiều câu hỏi"!
linkedlinked

Câu trả lời:


8

Bạn đang lạm dụng worker_threads của Nginx. Hoàn toàn không cần phải chạy nhiều công nhân. Bạn nên chạy nhiều công nhân như bạn có CPU và gọi nó là một ngày. Nếu bạn đang chạy gunicorn trên cùng một máy chủ, có lẽ bạn nên giới hạn nhân viên nginx xuống còn hai. Mặt khác, bạn sẽ phá hủy CPU với tất cả các chuyển đổi ngữ cảnh cần thiết để quản lý tất cả các quy trình đó.


1
À, cảm ơn. Hiệu suất có vẻ tương đương với 64 như với 2, nhưng tôi biết không phải WTF đang làm. Cảm ơn đã làm rõ.
linkedlinked

Bạn có thể chia sẻ cấu hình Nginx của bạn? Thật khó để cung cấp các mẹo điều chỉnh khi chúng tôi không biết những gì chúng tôi đang điều chỉnh.
blueben

2

Tôi đã sử dụng nginx để phục vụ yêu cầu 5K một giây cho nội dung tĩnh. Bạn có thể tăng số lượng worker_connections hiện được đặt thành 1024.

Tính toán max_client sẽ như sau.

Các worker_connections và worker_proceses từ phần chính cho phép bạn tính giá trị maxclents:

max_clents = worker_ Processes * worker_connections

Trong tình huống proxy ngược, max_clents trở thành

max_clents = worker_ Processes * worker_connections / 4

http://wiki.nginx.org/EventsModule#worker_connections

Tính toán các kết nối công nhân tối đa là dễ dàng một khi bạn biết khả năng thiết lập của mình. Tổng dung lượng / số lõi là kết nối công nhân tối đa. Để tính tổng công suất có nhiều cách.

  1. Tôi sẽ đề nghị bạn thử và điểm chuẩn thiết lập của bạn sẽ cung cấp cho bạn những con số thực tế nhất. Bạn có thể sử dụng các công cụ như bao vây, pummel, băng ghế dự bị, v.v., hãy nhớ để đo mức độ sử dụng tài nguyên hệ thống trong quá trình thử nghiệm.

Nếu phương pháp trên không phù hợp với bạn thì hãy thử các phương pháp dưới đây. Tôi đang thực hiện các giả định rộng rãi bỏ qua RAM và IO, chúng cũng sẽ có yếu tố nhưng chúng sẽ cho bạn điểm bắt đầu và bạn có thể điều chỉnh từ đó.

  1. Giả sử rằng băng thông là nút cổ chai, lấy kích thước đối tượng trung bình mà nginx đang phục vụ và chia băng thông của bạn với điều đó và bạn sẽ nhận được qps được hỗ trợ tối đa.

  2. Trong giả định thứ hai, CPU là nút cổ chai. Trong trường hợp này, đo thời gian yêu cầu và chia 1 cho nó và bội số với số lõi trong hệ thống của bạn. Điều này sẽ đưa ra số lượng yêu cầu mỗi giây nginx có thể xử lý.


Làm thế nào một người nên đi về việc xác định xem bạn có thể tăng worker_connections hay không và cài đặt lý tưởng cho một máy chủ nhất định là gì?
Kato

Có một vài cách để đi về điều này.
Sameer
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.