У меня есть служба, в которой серверы загружают на мой сервер XML-файлы размером 20 КБ.
Сессии нет, это единичный запрос POST и все. Каждый индивидуальный запрос аутентифицируется на основе содержимого файла xml.
Есть настройки, связанные с сокетами, которые мне придется сделать, так как во время нагрузочного тестирования сервер исчерпывает свой пул сокетов (32K).
Во всяком случае, мне было интересно, что может измениться, когда я добавлю балансировщик нагрузки в уравнение, которое будет выполнять циклические запросы между 2+ веб-серверами.
Может ли балансировщик нагрузки повторно использовать сокеты?
Опять же, просто хочу внести ясность, клиентские серверы отправляют файл на мой сервер, после того, как файл был отправлен по http, они на 100% завершены. Любые последующие сообщения http будут считаться новой «транзакцией».
Все ведущие балансировщики нагрузки имеют форму повторного использования и объединения соединений, они просто называют это по-другому. В конечном итоге они предназначены для очень быстрой и эффективной обработки пакетов.
F5 называет это OneConnect, Netscaler TCP мультиплексированием ... Я недостаточно знаю о других поставщиках или решениях с открытым исходным кодом.
Эта функция позволяет подсистемам балансировки нагрузки повторно использовать TCP-соединения на стороне сервера и значительно повышает производительность веб-приложения на стороне сервера. Когда соединение, так сказать, завершено, оно перемещается в пул повторного использования на балансировщике нагрузки и сопоставляется с последующим подключением, если это подходит (если это не подходит, балансировщик нагрузки откроет новое TCP-соединение с сервером). Нет разрыва соединения, поэтому нет необходимости в последующих трехсторонних рукопожатиях при новых соединениях или в том, чтобы сервер назначал или удалял память, назначенную открытым сокетам. Также следует отметить, что соединения на стороне сервера являются последовательными, а не конвейерными.
Без повторного использования соединения это соотношение 1-1 (между клиентом и сервером), и, по моему опыту, производительность (приложения) резко снижается, а нагрузка на внутренний сервер намного выше. Если это трафик SSL, вы увидите, что ЦП падает из-за обмена ключами.
Я предполагаю, что вы имеете в виду SO_REUSEADDR, а не мультиплексирование соединений. Единственное преимущество, которое это дает, заключается в том, что сокет в TIME_WAIT не предотвращает привязку нового сокета к тому же адресу. Я никогда не встречал систему, которая фактически использует фазу TIME_WAIT для того, для чего она предназначена - если у вас много сокетов в TIME_WAIT, возможно, вам следует просто уменьшить тайм-аут.
Ускорение процесса тоже поможет, но вы не предоставили много информации о настройке и структуре трафика.
Любой тип балансировщика нагрузки прокси даст вам еще меньше клиентских подключений, чем у вас есть сейчас (поскольку каждое входящее соединение требует подключения к внутренним устройствам). OTOH RRDNS сократит нагрузку вдвое без сложности и стоимости SPOF.
это один запрос POST
Итак, мы говорим здесь о HTTP? Если так, то есть ОГРОМНЫЙ простор для настройки.
Думаю, это будет зависеть от балансировщика нагрузки. Я знаю, что у F5 есть функция под названием OneConnect что позволяет подсистеме балансировки нагрузки мультиплексировать несколько запросов на открытие сокетов. Это снижает накладные расходы на создание / удаление сокетов для каждой транзакции протокола более высокого уровня.
Я знаю, что у других балансировщиков нагрузки есть аналогичные функции, хотя я не так хорошо знаком с ними.