У меня относительно новый 8-ядерный компьютер под управлением CentOS. Я хотел бы разработать сервер статистики, использующий TCP. Это очень просто: он принимает TCP-соединение, увеличивает счетчик и закрывает соединение. Уловка в том, что это нужно делать не менее 10 тысяч запросов в секунду. Я подозреваю, что процессор / память не будет проблемой, но меня больше беспокоят искусственные ограничения (например, полуоткрытые соединения), которые мне, возможно, придется настроить на моем сервере, чтобы разрешить такой объем. Так возможно ли это? О каких настройках мне следует знать? Моя сетевая карта не справится с этим?
Это широко известно как c10k проблема. На этой странице есть много полезной информации о проблемах, с которыми вы столкнетесь.
вы должны уметь это делать [хотя, вероятно, это плохая идея].
на смола appserv я могу получить ~ 5 тыс. запросов / сек на четырехъядерном процессоре xeon с частотой 2,6 ГГц. запросы вызывают простой сервлет, который читает 1 строку из mysql и отправляет очень маленький ответ в формате xml.
тест проводился с
ab -n 10000 -c 16 http://some/url/
результаты теста:
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
но я думаю, вам будет намного лучше использовать простую программу c, конечно, без создания новых потоков для каждого запроса. ссылка от Грега Хьюгилла должна дать вам хорошее представление об этом.
даже во время длительного теста у меня не возникает проблем с подключением [упоминались полуоткрытые сокеты]; Тест выполняется между двумя Linux-системами, подключенными через гигабитный Ethernet [хотя, как вы видите, пропускная способность не является узким местом].
Вас может заинтересовать предел ядра Linux, который я достиг при нагрузочном тестировании Apache. В моем случае ядро выдавало несколько полезных сообщений об ошибках, поэтому я советую писать свою программу, и если вы, кажется, достигли предела, обратите внимание на журналы ядра.
Ваш ник должен быть в состоянии справиться с этим, но я сомневаюсь в том, что дизайн будет иметь 10 тысяч новых TCP-соединений в секунду; если вы создаете / разрушаете соединения так быстро, то вам следует либо а) держать их открытыми дольше, либо б) использовать вместо этого UDP.
В случае, если у вас 1 млн клиентов, которым время от времени необходимо выполнять запросы, но когда нагрузка достигает 10 КБ в секунду, UDP, вероятно, будет лучшим выбором.
В случае, если у вас есть только 10 тысяч клиентов, которым нужно выполнять запрос каждую секунду, они могут просто держать существующие соединения открытыми и повторно использовать их. Это было бы намного удобнее для ОС, а также привело бы к намного меньшей задержке, поскольку не требовало бы нового рукопожатия каждый раз.
В случае, если у вас 10 тыс. Запросов в секунду, я полагаю, что у вас в любом случае есть интерфейсный балансировщик нагрузки, поэтому вам также нужно будет протестировать его.
(NB: я думаю, что это принадлежало Stack Overflow)
Если возможно, я бы использовал UDP вместо TCP. Он должен быть более легким и, следовательно, лучше масштабироваться.