многопоточность — оптимизировать алгоритм PHP с огромным количеством потоков?

Как часть Laravel приложение на основе я пытаюсь написать PHP скрипт, который выбирает определенные данные, то есть постоянно обновляется, через Интернет о некоторых продуктах, точнее, книгах.

Книги идентифицируются по ISBN, 10-значный идентификатор. Первые 9 цифр могут быть 0-9, в то время как последняя цифра может быть 0-9 или X. Однако последняя цифра является контрольной цифрой, которая рассчитывается на основе первых 9 цифр, таким образом, на самом деле существует только 1 возможная цифра за последнее место.

В таком случае мы приходим к:

10*10*10*10*10*10*10*10*10*1 = 1,000,000,000

численно правильные номера ISBN. Я могу сделать это немного лучше, если я ограничу свой поиск английскими книгами, поскольку они будут содержать только 0 или 1 в качестве первой цифры. Таким образом я бы получил:

2*10*10*10*10*10*10*10*10*1 = 200,000,000

численно правильные номера ISBN.

Теперь для каждого ISBN у меня есть 3 HTTP запросы, необходимые для получения данных, каждый из которых занимает примерно 3 секунды. Таким образом:

3seconds*3requests*200,000,000ISBNs = 1,800,000,000 seconds
1,800,000,000seconds/60seconds/60minutes/24hours/365days = ~57 years

Надеюсь, через 57 лет книги больше не будет, и этот алгоритм устареет.

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

Таким образом, проблема в том, как оптимизировать этот алгоритм, чтобы сократить время его работы с 57 лет до одной недели?

1) Самое первое, что вы заметите, это то, что, хотя существует 200 000 000 возможных ISBN, не существует такого большого количества реальных ISBN, что означает большинство этот алгоритм будет проводить время изготовление http запросы на ложные номера ISBN (Я мог бы перейти к следующему ISBN после первого неудачного http-запроса, но это само по себе не приведет к значительному снижению времени). таким образом решение 1 будет получить / купить / скачать база данных который уже содержит список используемых ISBN, таким образом, значительно сокращая количество ISBN для поиска.

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

2) Хотя этот алгоритм работает вечно, большую часть времени он просто сидит без дела ожидание для http ответ. Таким образом, одним из вариантов может быть использование Потоки.

Если мы посчитаем, я думаю, уравнение будет выглядеть так:

(numISBNs/numThreads)*secondsPerISBN = totalSecondsToComplete

Если мы изолируем numThreads:

numThreads = (numISBNs * secondsPerISBN) / totalSecondsToComplete

Если наш порог составляет одну неделю, то:

totalSecondsToComplete = 7days * 24hrs * 60min * 60sec = 604,800seconds
numISBNs = 200,000,000
secondsPerISBN = 3

numThreads = (200,000,000 * 3) / 604,800
numThreads = ~992

Так +992 потоки должны работать одновременно, чтобы это работало. Это разумное количество потоков для запуска, скажем, DigitalOcean сервер? Мой Mac прямо сейчас говорит, что на нем работает более 2000 потоков, так что, возможно, это число на самом деле управляемо.

1) Есть +992 разумное количество потоков для запуска на DigitalOcean сервер?
2) Есть ли более эффективный способ асинхронного выполнения этого алгоритма, поскольку каждый HTTP запрос полностью независим от любого другого? Каков наилучший способ держать процессор занятым в ожидании всех HTTP запросы на возврат?
3) Есть ли какая-то особая услуга, к которой я должен обратиться за этим, которая может помочь достичь того, что я ищу?