История изменений
Исправление OSBuster, (текущая версия) :
в смысле нет.
Есть.
Там в docker-compose.yml задаётся всем тестируемым cpus: 2
Там где application server это Puma, то он запущен независимо в двух процессах параллельных, в каждом процессе стоит значение в минимум 4 и максимум 20 тредов.
threads 4, 20
workers ENV.fetch("WORKERS").to_i
Там где application server это Falcon, то он тоже запущен с двумя воркерами, но традиционные треды, в отличие от Puma, не используют, а использует новомодные легковесные fibers, которые спаунит в каждом из этих двух воркеров сколько ему требуется, используя async библиотеку.
count ENV.fetch("WORKERS").to_i
У питоновсого Uvicorn тоже в настройках workers = int(os.getenv("WORKERS")) который равен 2. Как там дальше внутри них работает питоновский async я не в курсе.
Т.е. каждому тестируему окружению выделили два ядра и два воркера и один и тот же контейнер с БД.
Исправление OSBuster, :
в смысле нет.
Есть.
Там в docker-compose.yml задаётся всем тестируемым cpus: 2
Там где application server это Puma, то он запущен независимо в двух процессах параллельных, в каждом процессе стоит значение в минимум 4 и максимум 20 тредов.
Там где application server это Falcon, то он тоже запущен с двумя воркерами, но традиционные треды, в отличие от Puma, не используют, а использует новомодные легковесные fibers, которые спаунит в каждом из этих двух воркеров сколько ему требуется, используя async библиотеку.
У питоновсого Uvicorn тоже в настройках workers = int(os.getenv("WORKERS")) который равен 2. Как там дальше внутри них работает питоновский async я не в курсе.
Т.е. каждому тестируему окружению выделили два ядра и два воркера и один и тот же контейнер с БД.
Исправление OSBuster, :
в смысле нет.
Есть.
Там в docker-compose.yml задаётся всем тестируемым cpus: 2
Там где application server это Puma, то он запущен независимо в двух процессах параллельных, в каждом процессе стоит значение в минимум 4 и максимум 20 тредов.
Там где application server это Falcon, то он тоже запущен с двумя воркерами, но традиционные треды, в отличие от Puma не используют, а использует новомодные легковесные fibers, которые спаунит в каждом из этих двух воркеров сколько ему требуется, используя async библиотеку.
У питоновсого Uvicorn тоже в настройках workers = int(os.getenv("WORKERS")) который равен 2. Как там дальше внутри них работает питоновский async я не в курсе.
Т.е. каждому тестируему окружению выделили два ядра и два воркера и один и тот же контейнер с БД.
Исправление OSBuster, :
в смысле нет.
Есть.
Там в docker-compose.yml задаётся всем тестируемым cpus: 2
Там где application server это Puma, то он запущен независимо в двух процессах параллельных, в каждом процессе стоит значение в минимум 4 и максимум 20 тредов.
Там где application server это Falcon, то он тоже запущен с двумя воркерами, но традиционные треды, в отличие от Puma не используют, а использует новомодные легковесные fibers, которые спаунит в каждом из этих двух воркеров сколько ему требуется.
У питоновсого Uvicorn тоже в настройках workers = int(os.getenv("WORKERS")) который равен 2. Как там дальше внутри них работает питоновский async я не в курсе.
Т.е. каждому тестируему окружению выделили два ядра и два воркера и один и тот же контейнер с БД.
Исходная версия OSBuster, :
в смысле нет.
Есть.
Там в docker-compose.yml задаётся всем тестируемым cpus: 2
Там где application server это Puma, то он запущен независимо в двух процессах параллельных, в каждом процессе стоит значение в минимум 4 и максимум 20 тредов.
Там где application server это Falcon, то он тоже запущен с двумя воркерами, но традиционные треды, в отличие от Puma не используют, а использует новомодные легковесные fibers, которые спаунит в каждом из этих двух воркеров сколько ему требуется.
У питоновсого Uvicorn тоже в настройках workers = int(os.getenv("WORKERS")) который равен 2. Как там дальше внутри них работает питоновский async я не в курсе.
Т.е. каждому выделили два ядра и два воркера.