UNIX сокет магия. Рекомендуется для высокопроизводительного применения? - PullRequest
1 голос
/ 29 июня 2011

Я использую для передачи accept() ed сокет между процессами, используя sendmsg(). Короче говоря, я пытаюсь создать простой балансировщик нагрузки, который может работать с большим количеством соединений без необходимости буферизовать потоковые данные.

Является ли это хорошей идеей при работе с большим количеством (скажем, сотен) одновременных TCP-соединений? Если это имеет значение, моя система - Gentoo Linux

Ответы [ 2 ]

3 голосов
/ 29 июня 2011

Вы можете поделиться дескриптором файла согласно предыдущему ответу здесь .

Лично я всегда внедрял серверы, используя предварительный форк.Родитель настраивает сокет прослушивания, порождает (пре-форки) дочерние элементы, и каждый дочерний элемент принимает блокировку.Я использовал каналы для родительского <-> дочернего общения.

1 голос
/ 29 июня 2011

Пока кто-то не сделает тест и не установит, насколько «сложно» отправить файловый дескриптор, это остается спекуляцией (кто-то может всплыть: «Эй, отправка дескриптора, как это очень дешево» ).Но вот так.

Вам (вероятно, читайте выше) будет лучше, если вы просто используете темы.Вы можете иметь следующий рабочий процесс:

  • Запустить пул потоков, которые просто ждут работы.В качестве альтернативы вы можете просто создать новый поток при получении запроса (это дешевле, чем вы думаете)
  • Использование epoll(7) для ожидания трафика (ожидание соединений + интересный трафик)
  • Когда приходит интересный трафик, вы можете просто отправить «задание» в один из потоков.

Теперь это обходит весь дескриптор, отправляющий часть.Так в чем же подвох?Уловка в том, что , если один из потоков падает, весь процесс падает .Так что вам решать тестировать и решать, что лучше для вашего сервера.

Лично я бы сделал это так, как изложил выше.Еще один момент: если рабочие являются детьми процесса, выполняющего принятие, отправка дескриптора не требуется.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...