Тестирование и профилирование. Что имеет смысл, и что хорошо работает, зависит от конкретного приложения.
В основном вам нужно определиться с двумя вещами:
- Количество рабочих процессов / потоков для генерации
- Размер кусков, над которыми они будут работать
Поиграйте с двумя числами и рассчитайте их пропускную способность (количество выполненных задач в секунду * количество рабочих). Где-то вы найдете хорошее равновесие между скоростью, количеством рабочих и количеством задач в чанке.
Вы можете сделать поиск правильного баланса еще проще, предоставив своим работникам кучу тестовых данных, в основном эталонный тест, и автоматически измеряя их пропускную способность при настройке этих двух переменных. Запишите пропускную способность для каждой комбинации рабочего размера / размера куска задачи и выведите ее в конце. Наивысшая пропускная способность - ваша лучшая комбинация.
Наконец, если длительность конкретной задачи действительно зависит от самой задачи (например, некоторые задачи занимают X время, а некоторые - X*3, то вы можете выбрать несколько подходов. В зависимости от Характер вашей входящей работы, вы можете попробовать один из следующих:
- Предоставьте свои исторические данные эталонного теста - набор реальных данных, которые будут обработаны, которые представляют фактический вид работы, который будет поступать в вашу рабочую сетку, и измерьте пропускную способность, используя эти примеры данных.
- Создание задач произвольного размера, которые пересекают спектр того, что, как вы думаете, вы увидите, и выбираете комбинацию, которая, кажется, работает лучше всего в среднем, для задач нескольких размеров
- Если вы можете прочитать данные в задании, и эти данные дадут вам представление о том, займет ли это задание
X время или X*3 (или что-то среднее), вы можете использовать эту информацию до того обработка самих заданий для динамического изменения размера рабочего / задания для достижения максимальной пропускной способности в зависимости от текущей рабочей нагрузки. Этот подход используется в Amazon EC2, где клиенты будут раскручивать дополнительные виртуальные машины, когда это необходимо для обработки более высокой нагрузки, и понижать их, например, при падении нагрузки.
Что бы вы ни выбрали, любая неизвестная проблема со скоростью почти всегда должна включать в себя некоторый демонстрационный бенчмаркинг, если скорость, с которой он работает, имеет решающее значение для успеха вашего приложения (иногда время обработки настолько мало, что оно незначительно) .
Удачи!