Какой алгоритм использовать, чтобы высчитать оптимальное количество задержки перед повторным обращением для API?

Ситуация: Есть API, на него обращается ПО "исполнителей" для получения задания. Есть проблема: заказов не всегда есть в таком количестве, чтобы "занять" всех исполнителей. Есть желание избежать запросов каждую секунду, и самостоятельно ориентировать исполнителей через сколько секунд попытаться обратиться ещё раз.

Вопрос: какой алгоритм для вычисления этого времени?

Алгоритм может быть неидеальным("коллеги" корректируют сейчас вручную), но желательно как можно близким к реальности.

Данные в распоряжении:

1. Количество исполнителей в системе.
2. Количество задач.

Думаю, придётся вводить поле "last_execution" чтобы высчитывать "активных" исполнителей за N время.

Нагрузка на БД по запросам

Количество исполнителей будет примерно ~15 000. Каждое обращение генерирует:

• 1 SELECT-EXIST запрос
• 1 SELECT-запрос с LEFT JOIN

Другие детали

• Никаких статистических данных, к сожалению, сейчас нет. Есть просто эмпирические данные коллег. Но в процессе работы можно будет скорректировать.
• Приложение на PHP 7.2. База данных MySQL. Я ищу алгоритм, ограничен языком PHP, но думаю что основная логика исполнения будет лежать на базе данных.

UPD: Примечание: Увы, установлено правило, что на стороне "клиентского ПО" нельзя ничего изменить. Данное "ПО" готово ориентироваться только на параметр "retry_after" с кол-вом секунд когда повторить.

UPD #2: "Простым языком"/Примером: Сегодня по заказам "негусто", штук 100 в час появилось. А 6000 исполнителей онлайн каждую секунду шлют запрос на проверку задач. А вчера было "погуще", 2000 заказов/час.

Как видим: нельзя установить какую-то одну задержку и "жить спокойно". Надо её регулярно(начнём хотя бы раз в день) обновлять.

А цель: оптимизация. Зачем серверу получать тысячи запросов в секунду, если заказов пока мало? Вот этот вопрос пытаюсь решить...