Почему увеличение количества threads не помогает?

Question

[Nastya1920]

В двух словах, новая версия клаудинговой платформы написана на базе kubernetes. У сервисов имеются контроллеры (reconcilers) для каждого типа объекта. Моя задача - увеличить количество concurrent reconciles для каждого контроллера, чтобы увеличить производительность.
Я построила и запустила море симуляций наших юзер-сценариев в gatling, конфигурируя разные количества потоков для контроллера. В результате - практически никакой разницы во времени респонсов. То есть увеличение количества потоков не дает результата...
В системе 4 cores
вопрос: как быть? Почему нет тенденцию к ускорению с увеличением числа потоков? Как тогда увеличить производительность системы?

Answer 1

[Василий Банников]

В системе 4 cores

Ну так у тебя четыре ядра - значит физически больше четырёх разных операций одновременно происходить не может.
Значит и больше 4х потоков создавать смысла нет.

Comments

[Nastya1920]

Конечно, я понимаю, но разницы нет даже в пределах между 1-4 потоками, хотя объективно должна быть, как я понимаю...

[Василий Банников]

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

Если 99% работы - это ожидание ответа от каких-то сетевых устройств, то тут аналогично - четыре потока, в лучшем случае, смогут сделать четыре одновременных запроса, но если эти запросы будут обрабатываться на устройстве последовательно, то ускорение будет заметно только в CPU-bound части, которая занимает 1% времени.

Так что расчехляй профайлер и смотри, на что уходит время.

Answer 2

[Vitaly Karasik]

У сервисов имеются контроллеры (reconcilers) для каждого типа объекта. Моя задача - увеличить количество concurrent reconciles для каждого контроллера, чтобы увеличить производительность.

Вы точно имеете в виду контроллеры K8S, а не кол-во подов?

А что еще есть в системе? База данных? Очередь?

Comments

[Nastya1920]

Да, речь о контроллерах (реконсайлерах). Что касается подов, для каждого сервиса создано по 2 пода в replicaset, один из которых обслуживает контроллеры сервиса, а второй вебхуки. В случае недоступности ведущего, второй подхватывает лидерство.

База данных - aws opensearch, для сервиса авторизации есть кэш (redis). Насчет очереди: насколько я знаю, все реконсайлеры используют очередь

[Vitaly Karasik]

Да, речь о контроллерах (реконсайлерах)

Сорри, тогда не знаю. Я на таком уровне в K8S не влезал. Во всех моих экспериментах увеличение кол-ва подов (вручную или с помощью HPA [autoscaling]) решало проблемы траффика.
То ли я чего-то не понимаю (это вполне может быть), то ли вы зря возитесь с контроллерами.

База данных - aws opensearch

Тогда советую посмотреть на нагрузку и slow query log opensearch, возможно тут слабое место.