Алгоритмы оптимизации очереди заданий

У нас есть приложение, которое требует назначения ресурсов ресурсам. Ресурсы имеют ряд атрибутов, которые определяют их пригодность для конкретной работы - некоторые из них являются предпочтениями, некоторые из них являются жесткими ограничениями (все разновидности членства, например "ресурс A подходит для заданий с цветом X, Y или Z".

Ресурсы имеют связанную с ними стоимость (продолжительность, которую они проводят в режиме онлайн). У нас есть возможность набирать ресурсы - это занимает много времени. Мы можем набирать в течение фиксированного интервала времени.

Чтобы дать представление о масштабе: в любой момент времени будет доступно около 20 ресурсов, 100 выдающихся заданий. Завершение работы занимает 5-15 секунд. Рекрутинг ресурса занимает около 1-2 минут, и мы можем набирать с 1 до 30 минут времени (разрешается повторная передача). У нас не так много хедз-ап на поданных работах, может быть, несколько секунд.

Целью является выполнение заданий с наименьшей стоимостью (использование ресурсов) для заданной средней латентности (время завершения задания).

Я хотел бы обратить внимание на алгоритмы, библиотеки программного обеспечения или подходы к решению этой проблемы.

Ответ 1

Возможно, вы захотите заглянуть в проблему рюкзак или bin упаковке, поскольку они в принципе схожи с тем, что вы пытаетесь сделать здесь.

В описании проблемы вы указываете, что целью является завершение работы с наименьшей задержкой. Если это на самом деле ваша единственная цель, то решение простое - нанять все доступные ресурсы. Многие из них будут простаивать большую часть времени, но это в значительной степени гарантирует минимально возможную задержку.

Я подозреваю, что ваша реальная цель состоит в том, чтобы как можно меньше свести к минимуму как латентность, так и незанятые ресурсы, поэтому всегда будет какая-то компромисс между латентностью и потерянными ресурсами здесь.

Ответ 2

Это похоже на несколько вещей: количество экономического заказа, балансирование авансовых затрат на набор с себестоимостью; LP или IP, сводя к минимуму формулу общей стоимости, подверженной различным ограничениям; и тогда есть распределения вероятности (время для набора, требуются рабочие ресурсы?), делая все стохастическое.

Звучит достаточно сложно, что, если бы я это делал, я бы, вероятно, создал симуляцию. Система не кажется слишком сложной для этого или слишком математически обременительной для запуска большого количества итераций или длительного времени, поэтому вы можете получить довольно стабильные и полезные результаты.

Ответ 3

Я бы посмотрел на него таким образом... не уверен, что он все покрывает.

1) "Ресурс" действительно можно рассматривать как "рабочий центр".. Сколько рабочих центров, которые вы открыли для работы над "заданиями", относится к тому, кто подписан в систему.

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

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

Я просто надеюсь, что вы не создаете исходящий колл-центр: P

Ответ 4

Я не знаю литературы по таким проблемам. Я предполагаю, что есть некоторые из них, поскольку теория массового обслуживания является большой академической областью, и это не похоже на смехотворно надуманную ситуацию. Имейте в виду, что вы заботитесь о средней латентности, а не о задержке в наихудшем случае или латентности Nth процентили, могут поставить вас в меньшинство.

Мой первый инстинкт заключается в том, что, поскольку вокруг, похоже, много рабочих мест, хорошее решение будет иметь несколько "гибких" рабочих, постоянно работающих. Это набор работников, которые между ними могут выполнять большинство типов общих заданий с приемлемой задержкой. Чем ниже вы хотите латентность, тем больше ресурсов в этом наборе и больше времени, которое они проводят в режиме ожидания. Кроме того, чем более "взрывным" является ваш вход (предполагая, что всплески непредсказуемы), тем больше времени требуется вам для предотвращения высокой латентности во время всплесков.

Затем в двух случаях вы нанимаете дополнительных "специализированных" работников:

1) Редкий тип работы заключается в том, что ваш текущий набор наемных работников может обрабатывать только при высокой стоимости или вообще не работать. Таким образом, вы нанимаете (грубо говоря) того, кто может его перенести, а затем делать все возможное из остальной части вашей очереди.

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

Что касается реального алгоритма: почти наверняка невозможно вычислить возможное решение наилучшим образом, поэтому правильный ответ зависит от ресурсов обработки, и вы смотрите на эвристику и решаете частичные проблемы. Пока все, кого вы нанимаете, заняты, и вы не можете нанимать кого-либо еще, не вызывая значительного простоя в какой-то момент в будущем, вы, вероятно, находитесь рядом с хорошим решением, а где-то рядом с "большинством бэков за доллар" "точка задержек/затрат. Привлечение большего количества ресурсов после этого уменьшает отдачу, но это не означает, что вы не хотите делать это за определенную задержку и/или указанный бюджет.

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

Кроме того, предположительно, если ресурсы являются людьми, вы не можете фактически гарантировать, что наем удастся. Они не собираются сидеть в течение всего дня, только получая деньги, когда есть работа поминутно, не так ли?

Ответ 5

Эта проблема может рассматриваться как проблема линейной оптимизации, поэтому this должно быть начато. Я использовал эту библиотеку, но в ней много чего другого, поэтому она может быть излишней. Вместо этого нетрудно разработать собственную библиотеку, в этой книге есть хорошая глава о LP.

Ответ 7

Удивительный вопрос!!

Я бы рассмотрел динамическое программирование, линейную оптимизацию и теорию массового обслуживания. К сожалению, я не могу ответить на эти вопросы. У меня нет математической экспертизы, необходимой для того, чтобы дать вам твердый, оптимальный ответ для этих вещей.

Однако, если вы увлекаетесь такими вещами, это похоже на возможность получить хорошее, хотя и не оптимальное, решение с использованием алгоритма искусственного интеллекта. Я бы пересчитал либо генетический алгоритм, либо смоделированный отжиг. Любой из них не займет много времени, чтобы закодировать. Идея состоит в том, что вы выбираете случайные, достоверные исходные данные, и вы можете настроить эти потенциальные решения, развивая их в лучшие (или автоматически выбирая новые) со временем. Это хороший компромисс между получением оптимальных ответов и тратой навсегда для кодирования и подтверждения правильности.

Ответ 8

Это очень похоже на Операционная система реального времени Планирование. В Википедии описаны некоторые из используемых алгоритмов:

  • Совместное планирование
    • Планирование с круговым расписанием
  • Упреждающее планирование
    • Упреждающее планирование с фиксированным приоритетом, реализация упреждающая нарезка времени
    • Предварительное планирование критического раздела
    • Статическое расписание времени
  • Самый ранний срок Первый подход
  • Расширенное планирование с использованием стохастического и MTG

Ответ 9

Несколько мыслей:

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

Если это так, то вы можете с самого начала уменьшить некоторую сложность, а затем использовать некоторую форму взвешенных средних для предпочтений. Кроме того, когда вы набираете, так как мин. вы можете набрать на 30 минут, и предположение, что они являются более высокой стоимостью, вы, вероятно, хотите убедиться, что они имеют самый высокий уровень использования.

Вот некоторые статьи, которые могут помочь: