Tôi đang thiết kế một hệ thống để xử lý 10000 kết nối TCP mỗi giây, tôi sẽ gặp phải vấn đề gì?


18

Tôi có một hộp 8 lõi tương đối mới chạy CentOS. Tôi muốn phát triển một máy chủ thống kê sử dụng TCP. Rất đơn giản, nó chấp nhận kết nối TCP, tăng bộ đếm và đóng kết nối. Điều hấp dẫn là nó cần phải làm điều này ít nhất 10k yêu cầu một giây. Tôi nghi ngờ CPU / Bộ nhớ sẽ không phải là vấn đề, nhưng tôi lo ngại hơn về các giới hạn nhân tạo (như kết nối nửa mở) mà tôi có thể cần phải định cấu hình trên máy chủ của mình để cho phép loại âm lượng này. Vì vậy, điều này là có thể? Những cài đặt nào tôi nên biết? Liệu NIC của tôi sẽ không thể xử lý nó?


1
đảm bảo không sinh ra các luồng cho mỗi kết nối đến, nó sẽ giết chết hiệu suất

1
+1 để báo cáo kết quả cuối cùng của bạn tại đây :)
agsamek

Câu trả lời:


17

Điều này thường được gọi là vấn đề c10k . Trang đó có rất nhiều thông tin tốt về các vấn đề bạn sẽ gặp phải.


vâng, liên kết tốt!
sybreon

1
Tôi hy vọng sẽ thấy nhiều vấn đề / khác nhau hơn những vấn đề được đề cập trên trang c10k. Thiết lập và đóng kết nối 10k mỗi giây khác với kết nối mở 10k. Các kết nối ở trạng thái TIME_WAIT sẽ là một, đạt giới hạn tồn đọng cho ổ cắm nghe có thể là một kết nối khác. Và tôi sẽ không ngạc nhiên nếu trường hợp sử dụng đó không nhận được nhiều hồ sơ / tối ưu hóa trong mã hạt nhân so với trường hợp kết nối mở 10k phổ biến hơn.
cmeerw

2

bạn sẽ có thể làm điều đó [mặc dù đó có thể là ý tưởng tồi].

trên ứng dụng nhựa tôi có thể nhận được ~ 5k req / giây trên lõi tứ 2.6ghz xeon. yêu cầu gọi servlet đơn giản đọc 1 hàng từ mysql và gửi phản hồi xml rất nhỏ.

kiểm tra đã được thực hiện với

ab -n 10000 -c 16 http://some/url/

kết quả kiểm tra:

Concurrency Level:      16
Time taken for tests:   1.904 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3190000 bytes
HTML transferred:       1850000 bytes
Requests per second:    5252.96 [#/sec] (mean)
Time per request:       3.046 [ms] (mean)
Time per request:       0.190 [ms] (mean, across all concurrent requests)
Transfer rate:          1636.42 [Kbytes/sec] received

nhưng tôi nghĩ bạn sẽ tốt hơn nhiều khi sử dụng chương trình c đơn giản, chắc chắn mà không sinh ra chủ đề mới cho mỗi yêu cầu. liên kết từ Greg Hewgill sẽ cung cấp cho bạn ý tưởng hay về nó.

ngay cả trong quá trình thử nghiệm kéo dài, tôi không gặp bất kỳ vấn đề nào với kết nối [các ổ cắm đã mở một nửa]; kiểm tra chạy giữa hai hộp linux được kết nối qua gigabit ethernet [mặc dù như bạn thấy băng thông không phải là nút cổ chai].


Các kết nối của bạn có bị đóng sau mỗi phản hồi như OP không? Là ab gửi kết nối: đóng tiêu đề?
Nate

1
@Nate đó là http 1.0 - kết nối duy nhất cho mỗi yêu cầu http.
pQd

1

Bạn có thể quan tâm đến giới hạn nhân Linux mà tôi đạt được trong khi tải thử nghiệm Apache. Trong trường hợp của tôi, kernel tạo ra một số thông báo lỗi hữu ích vì vậy lời khuyên của tôi là viết chương trình của bạn và nếu bạn dường như đang đạt đến giới hạn, hãy chú ý đến nhật ký kernel.


0

Tôi sẽ sử dụng UDP thay vì TCP nếu có thể. Nó nên nhẹ hơn và do đó quy mô tốt hơn.


Tôi đồng ý. UDP sẽ nhẹ hơn nhiều
fpmurphy

1
UDP có những nhược điểm, như xác minh người gửi và phân phối, vì vậy người ta nên xem xét chúng trước khi sử dụng UDP trong sản xuất.
LưuTheRbtz

0

Nic của bạn sẽ có thể xử lý nó, nhưng tôi nghi ngờ thiết kế có 10k kết nối TCP mới mỗi giây; nếu bạn đang tạo / hủy kết nối nhanh chóng, thì bạn nên a) giữ chúng mở lâu hơn hoặc b) sử dụng UDP thay thế.

Trong trường hợp thỉnh thoảng bạn có 1M khách hàng cần thực hiện truy vấn, nhưng khi tải sẽ đạt 10k mỗi giây, UDP có lẽ là lựa chọn tốt hơn.

Trong trường hợp bạn chỉ có 10k khách hàng cần thực hiện truy vấn mỗi giây, họ chỉ có thể giữ các kết nối hiện có mở và sử dụng lại chúng. Điều này sẽ tốt hơn nhiều so với HĐH và cũng tạo ra độ trễ ít hơn rất nhiều vì nó sẽ không yêu cầu bắt tay mới mỗi lần.

Trong trường hợp bạn có 10k yêu cầu mỗi giây, tôi tưởng tượng bạn có bộ cân bằng tải phía trước, vì vậy bạn cũng cần phải kiểm tra điều đó.

(NB: Tôi nghĩ rằng điều này thuộc về Stack Overflow)

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.