Версия 1.1.811. Имеем парсер, который добавляет запросы в темплейте с использованием функции tools.query.add(url) и ограничивает парсинг в зависимости от query.lvl. Уникализация запросов включена. Папки tasks и queries в порядке теста были подмонтированы из ram как tmpfs, чтобы снизить влияние скорости винчестера на показатели. Парсинг пробовал стартовать как с с кол-вом запросов, значительно большим, чем кол-во потоков, так и с одним. Получили с самого начала старта парсинга: 1) ограничение query.lvl=10, скорость парсинга 21К запросов в минуту 2) ограничение query.lvl=1000, скорость парсинга 13К запросов в минуту Методом пробок и ошибок, а также подключения в консоли к БД {task_id}_additional.db было выяснено, что парсер стремится углубить процесс с момента старта, несмотря на то, что на нижних уровнях полно запросов, которые нужно выполнить и в самом файле запросов есть еще невыполненные запросы. Что хотелось бы получить - пока есть запросы на нижних уровнях query.lvl и/или есть данные в файле запросов , не исполнять запросы на уровнях выше. Тогда производительность при текущей архитектуре ПО будет падать с течением времени, а не с самого начала старта парсинга. Так же в некоторых специфических задачах важно, чтобы запросы выполнялись последовательно. Или я что-то не понимаю и делаю не так, а то, что мне нужно и так есть, а я просто не знаю как это "готовить".
мы углубляемся что бы запросы не разрастались, если парсить все нулевые уровни, потом все первые, и т.д. мы к 10 уровню получим миллиарды необработанных запросов, не говоря о том что это сломает другую логику
Ok, реализовал workaround - по api создаются крохотные задания, потом результат обрабатывается сторонним скриптом, создается опять крохотное задание и так далее по кругу. На выходе получил максимально возможную скорость сбора данных и в нужной мне последовательности(имитация Fifo queue).
