Боюсь, это уже за пределами здравого смысла для инструмента (Парсер).

andylars 24.01.2017 19:39 / 24.01.2017 19:40

Ситуация, которую вы описали - типичная архитектура подсистем и под-сервисов, которые, при разной скорости обслуживания обработки - разруливаются через сервис очередей (MOM - Message-Oriented Middleware), из известных это RabbitMQ или проч.

В любом случае в этом паттерне, уже многое сложилось, и некий стандарт (AMQP (Advanced Message Queuing Protocol) и некий протокол. И типовые ситуации.

Даже наколенная архитектура подсказывает, что держать 10 сек и более (полчаса, час?) процесс, который обслуживает клиентский HTTP-запрос - как-то неправильно (ну только если это не бесконечный push/чат).

Что мешает процессу не делать прямой запрос туда, где у вас "долго и занято".
А положить в промежуточную базу-очередь. И тут же в течение 2-3 сек попытаться забрать из этой очереди ответ.

Если ответа нет, значит в ~2-3 сек завершить процесс с HTTP-ответом, где сказано, что "Обработка потребует времени". Можно помариновать юзера на этой же странице - дав ему какой-нить js-прогресс-бар, а можно даже отпустить походить по сайту/сервису, сказав, что как только данные будут готовы (мы вам нотификацию в шапку пришлём или даже средиректим) - тут уйма вариантов.


Можно играть или созданными для этого инструментами, или своими, но смысла натягивать "сову на глобус" через flock, когда есть mysql(memory-table)/memcached - не вижу.

---