В версии 2.7 мы переработали несколько областей связи между мастер-демоном и удаленными агентами. Изменения происходят “под капотом”, решая проблемы, которые сказываются в определенных сценариях или при высоких нагрузках с использованием распределенных индексов с удаленными узлами.

Асинхронный DNS

Это была своего рода проблема, особенно для пользователей облачной инфраструктуры. На Linux демону будет использоваться getaddrinfo_a() при наличии для асинхронного DNS. Это означает, что нам не нужно активно ждать ответа, вместо этого мы планируем задачу, и когда (если) DNS ответит, мы продолжаем - или прерываем после некоторого времени по тайм-ауту. На системах, где getaddrinfo_a недоступен, мы создаем новый поток, посвященный разрешению DNS (что также работает асинхронно).

Сетевые потоки удаленных агентов

Когда запрос поступает к распределенному индексу с удаленными агентами, мы порождали много потоков, чтобы подключиться и отправить запрос, затем ждали, пока все они закончат, чтобы перейти к следующим этапам. Проблема здесь в том, что если один узел отвечает медленно, это может замедлить весь процесс. Вместо того, чтобы отправлять запрос для каждого узла, который ответил, им приходилось ждать, пока все будут готовы. В общем, это могло значить драгоценное время бездействия и увеличение общего времени ответа на запрос. Теперь каждое соединение работает независимо от начала до завершения, и их участие в исполнении не зависит (не замедляется) от возможных более медленных узлов. Связано с этим, первый шаг в предыдущих версиях заключался в том, чтобы действительно разделить черные дыры агентов от нормальных агентов, так как, в прошлом, хотя мастер не должен был ждать ответа от черной дыры, он все равно ждал первоначальный ответ от нее - и проблемная черная дыра могла замедлить весь запрос.

API proto

Третье улучшение в отношении сети связано с API proto. В предыдущих версиях соединение между мастером и удаленным агентом начиналось с ‘handshake’ - небольшого пакета, содержащего версию API. Другой конец линии отвечал своей версией, и если все в порядке, запрос начинался. Этот handshake был настроен в представлении, что адрес/порт в конфигурации агента могут быть неверными, и не отправлять более крупный пакет в этом случае. Однако мы увидели это как пустую трату времени (учитывая сетевые задержки) и пропускной способности, чтобы просто проверить, правильно ли пользователь настроил все. Это менее вероятно, чем произойдет, и даже если это так, это можно исправить пользователем. Вместо этого теперь этот ‘handshake’ отправляется вместе с запросом в одном пакете, что сокращает общее время, затрачиваемое на запрос к удаленному узлу. Если удаленный хост действительно неправильный, мы просто отправили пакет напрасно, но это может быть замечено пользователем и исправлено - нам не нужно постоянно это проверять. Это изменение proto сохраняет совместимость со старым proto, таким образом, если мастер обновлен до 2.7+, он по-прежнему сможет взаимодействовать с удаленными агентами на < 2.7.

TFO для мастер-узлов

Последнее улучшение касается TCP Fast Open - в предыдущих версиях мы добавили возможность для клиентов использовать tfo соединения при подключении к поисковому демону. Теперь TFO-соединения также могут использоваться в распределенном индексе между мастером и удаленными агентами. Изменения в конфигурации не требуются, демоны обнаружат, доступен ли TFO на хост-системе, и просто используют его.