Рекомендации по конфигурированию тестовой среды

[batonio]

Согласно изложенному в статьях

https://habrahabr.ru/post/201826/
https://habrahabr.ru/company/yandex/blog/240525/

описанию работы проекта(плюс, естественно, сам код Synca) успешно скрестил синхронные сетевые интерфейсы нашей пользовательской библиотеки с другой нашей библиотекой асинхронного сетевого взаимодействия.

Tак как при работе условного сервера и множества(от нескольких сотен) условных клиентов на одной и той же машине упираемся в лимиты операционной системы(Ubuntu 14.04)

TCP: request_sock_TCP: Possible SYN flooding on port . Dropping request.  Check SNMP counters.

, то внезапно встал вопрос, при каких условиях было достигнуто значение в 30K RPS?

Cкладывается плохое ощущение что не помогают никакие тюнинги
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_syncookies
net.core.somaxconn

Хотя судя по временным меткам сетевого дампа тех небольших успешных количеств запросов-ответов можно судить о том, что производительность в 30K RPS на одно ядро вполне себе реальна.

[gridem]

Попробуй эту опцию: http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/ip__tcp/no_delay.html

[batonio]

Не помогло.
В любом случае спасибо, продолжу после праздников

P.S.
Если интересно, в аттаче то, так выглядит сетевой диалог
12345.cap.zip
С какого-то момента появляются секундные задержки на посланный клиентом SYN и как следствие [TCP Retransmission]
Всё это вместе с появлением

Mar  8 11:41:34 true kernel: [70231.929904] TCP: request_sock_TCP: Possible SYN flooding on port 12345. Dropping request.  Check SNMP counters.

[gridem]

Обычно эта опция помогает. Можете привести фрагмент кода с выставлением этой опции?

[batonio]

То как рисует в лог strace(режим клиента и сервера на одной машине)

...
Process 10318 attached
Process 10319 attached
Process 10321 attached
Process 10320 attached
Process 10322 attached
Process 10323 attached
[pid 10323] 13:10:18.360849 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 19
[pid 10323] 13:10:18.360973 setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 10323] 13:10:18.361017 bind(19, {sa_family=AF_INET, sin_port=htons(44652), sin_addr=inet_addr("172.16.0.130")}, 16) = 0
[pid 10323] 13:10:18.361061 listen(19, 10) = 0
[pid 10323] 13:10:18.361089 setsockopt(19, SOL_TCP, TCP_NODELAY, [1], 4) = 0
First connection
[pid 10319] 13:10:18.375104 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 20
[pid 10320] 13:10:18.390432 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 22
[pid 10319] 13:10:18.390590 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 23
[pid 10321] 13:10:18.390792 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 25
[pid 10321] 13:10:18.391133 socket(PF_INET, SOCK_STREAM, IPPROTO_IP 
[pid 10320] 13:10:18.391150 socket(PF_INET, SOCK_STREAM, IPPROTO_IP 
...

З.Ы.
К сожалению сейчас нет времени копнуть глубже.
Проверял работу данного подхода на разных машинах в двух вариантах

1. Сервер nginx + клиент на сопрограммах
2. Сервер на сопрограммах + в качестве клиента утилита wrk(https://github.com/wg/wrk.git)

Получил 8-11 тыс запросов-ответов на одно ядро. На данный момент этого достаточно с запасом на пару порядков.
К вопросу "выжать максимум" вернусь сильно позже((