параллельный вызов accept

backlog это не про то. То что ты имеешь ввиду называется TCP_QUICKACK

параметр backlog в listen влияет на очередь УЖЕ установленных соединений. Очередь в ядре зависит от этого параметра net.ipv4.tcp_max_syn_backlog, и там и там бэклог так что ты перепутал

Кстати, вот тут списочек настроек сервера http://romantelychko.com/blog/1300/ там не указано изменение параметра nofile в /etc/security/limits.conf. Ведь это по сути самый важный параметр который позволит нам открыть указанное в нём число дескрипторов. Это там про него забыли или он чем-то заменяется там? Я вот не нашел, а ты где берёшь инфу по настройкам сервера?

параметр backlog в listen влияет на очередь УЖЕ установленных соединений

в классическом варианте это не так. Backlog это очередь на accept, а установление соединения происходит только после accept.

Accept в event loop заметно просаживается по latency когда есть много других событий на обработку. Accept в отдельном треде работает мгновенно

Каким образом accept может просадить производительность? После poll он должен работать мгновенно.

Если прилетело много событий на обработку то до accept может очередь не сразу дойти

я где-то читал( опять не помню где) что в какой-то момент поменяли логику как я описал, а до этого было по твоему

дело в том что часть кода функции accept требует монопольного доступа к чему-то там, потому и возникает очередь в случае множественного вызова accept, это и просаживает производительность

незнаю насчет классики времен динозавров, но нынче соединение становится доступным приложению по accept только после 3-way TCP handshake.

Можно пойти дальше и установить TCP_DEFER_ACCEPT и тогда приложению по accept будут возвращаться только те соединения, в которых уже есть байты с данными.

во во, про то я и говорил, а параметр TCP_DEFER_ACCEPT очень хорош когда сервер помимо соединения должен ещё принять auth данные.

часть кода функции accept требует монопольного доступа к чему-то там, потому и возникает очередь в случае множественного вызова accept

Очередь, если она и возникает, тормозит только одновременные accept. Но, если перед accept делается poll, возникнуть ей неоткуда.

как на это влияет полл? на слушающий сокет есть одна очередь, ацепт пробуждается когда в ней есть запрос на коннект, о том что есть запрос на коннект сообщает полл, далее ацепт требует монопольный доступ к этой очереди как я понял, если взять 100 одновременных коннектов и 100 потоков с вызовов ацепт, то грубо говоря в каждом потоке полл даст отмашку ацепту который в свою очередь встанет в очередь. Если я не так понимаю принцип объясни как правильно, а не просто: «полл всё делает чётко, всем спасибо всем пока».