Я разрабатываю API отдыха, который рассчитывает все возможные пути и связи между двумя точками в расписании автобусов. Чтобы достичь точки B из точки A, может быть комбинация нескольких шинных линий, скажем, что я могу достичь этой точки, взяв
bus line A -> bus line B -> bus line C
, но также
bus line D -> bus line E -> bus line C.
Для каждой ссылки, скажем, от шины A до шины B, мне нужно рассчитать все возможные ссылки в указанное время, а затем для каждой комбинации найти все комбинации с шиной C.
. Окончательный результат между 3 строками получается примерно за 1 сек. c. Это нормально, но для комбинации из 20 групп по 3 строки, требуется слишком много времени, чтобы ответить каждому клиенту (который является конечным пользователем), который запрашивает поэтому я подумал реализовать рабочие потоки, чтобы перераспределить каждый cal c.
Это хороший сценарий для реализации рабочих потоков? Сколько ниток, с хорошей практикой, я могу начать? Сначала я думал о том, чтобы начать новый поток для каждой комбинации из 3 строк (в моем примере это 20 рабочих потоков для 20 комбинаций из 3 строк в каждой), но я не знаю, означает ли это очень высокое использование ресурсов (каждый cal c означает очень мало запросов к БД, медлительность заключается в том, что для каждой автобусной остановки вызывается рекурсия для поиска ссылок).