Оптимизация Linux Socket

Question

Я бы хотел задать несколько вопросов по оптимизации сокета Linux.Я пытаюсь сделать многопоточный loadbalancer, используя boost и простой сокет linux.Loadbalancer работает так же просто, как эти шаги:

1. Запрос приходит, и слушатель tcp примет сокет, просто произнесите его clientSocket и создайте новый поток
2. Когда поток запускается, он создаст внутренний сокет, просто произнесите его serverSocket для внутреннего сервера (службы)
3. После того как serverSocket установлен,Я создаю новый поток для чтения из serverSocket и отправляю данные / ответ на clientSocket
4. А для основного потока я вызываю функцию, которая будет читать из clientSocket и отправить на serverSocket
5. Когда один из этих двух сокетов станет недействительным, рабочий закроет оба сокета и умрет

Я такжеиспользуйте Waitset из библиотеки ting, которая использует epoll, чтобы сделать метод recv в режиме блокировки, чтобы он ожидал, пока не произошло событие, а затем считал данные из сокета.

Проблема в том, что япроверил лoadbalancer с AB, -n 10000 -c 100 -k, результат очень разочаровывает.Я получил только ~ 1600 тпс.Я пытался записать время запроса для каждого запроса, но результат был хорошим.Каждое путешествие туда и обратно получало <1000 микросек / 1 милисек.</p>

Но когда я регистрирую интервалы входящего запроса, следующий запрос обрабатывается около> 5000 микросек / 5 миллисекунд от текущего полученного запроса.Может быть, кто-нибудь может предложить лучшее решение для оптимизации работы сокета здесь?Спасибо.

Answer 1

Вы делаете это слишком сложным. Поток на соединение не выходит за рамки тривиальных примеров, для получения более подробной информации прочитайте проблему C10K .

Предлагаю прочитать о библиотеке Boost.Asio для вашего балансировщика нагрузки. Он использует epoll(4) в системах Linux для демультиплексирования асинхронных событий и будет масштабироваться намного лучше, чем поток на соединение.

Answer 2

Ну, проблема заключается в том, что вы создаете один поток на соединение.Это не будет хорошо масштабироваться.Так почему бы вам не создать один поток, который просто следит за входящим запросом соединения и событиями in / out / hup с помощью epoll.Поток не делает ничего другого, чтобы сделать его простым и эффективным.Когда данные доступны, передайте их потоковым работникам, которые выполняют эту работу.Вы можете присоединиться к потоку событий и рабочим потоков (пул потоков, созданный при инициализации) с помощью очередей ввода / вывода.

Что ж, если это недостаточно эффективно при наличии большого количества соединений, вы можете сбалансировать соединенияв мультипроцессах.Затем модель становится такой, что вы инициализируете несколько дочерних процессов во время инициализации и передаете сокет сервера каждому из них.Когда приходит запрос на соединение, каждый из дочерних процессов имеет возможность принять.Реальная балансировка нагрузки с использованием нескольких процессов.

Согласно приведенной выше модели, более 20 000 подключений на одном сервере не являются проблемой.Надеюсь, что это поможет вам:)