1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.
  2. Вступайте в наш Telegram чат: https://t.me/a_parser Нас уже 2600+ и мы растем!
    Скрыть объявление

Ошибка Net::HTTP падение производительности, tools.query.add, query.lvl

Тема в разделе "Отклоненные задачи", создана пользователем Boomerc, 10 апр 2017.

  1. Boomerc

    Boomerc A-Parser Enterprise License
    A-Parser Enterprise

    Регистрация:
    15 мар 2017
    Сообщения:
    35
    Симпатии:
    16
    Версия 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 и/или есть данные в файле запросов , не исполнять запросы на уровнях выше. Тогда производительность при текущей архитектуре ПО будет падать с течением времени, а не с самого начала старта парсинга. Так же в некоторых специфических задачах важно, чтобы запросы выполнялись последовательно. Или я что-то не понимаю и делаю не так, а то, что мне нужно и так есть, а я просто не знаю как это "готовить".
     
    Metroid нравится это.
  2. Forbidden

    Forbidden Administrator
    Команда форума A-Parser Enterprise

    Регистрация:
    9 мар 2013
    Сообщения:
    3.336
    Симпатии:
    1.791
    мы углубляемся что бы запросы не разрастались, если парсить все нулевые уровни, потом все первые, и т.д. мы к 10 уровню получим миллиарды необработанных запросов, не говоря о том что это сломает другую логику
     
  3. Boomerc

    Boomerc A-Parser Enterprise License
    A-Parser Enterprise

    Регистрация:
    15 мар 2017
    Сообщения:
    35
    Симпатии:
    16
    Ok, реализовал workaround - по api создаются крохотные задания, потом результат обрабатывается сторонним скриптом, создается опять крохотное задание и так далее по кругу. На выходе получил максимально возможную скорость сбора данных и в нужной мне последовательности(имитация Fifo queue).
     
    Metroid нравится это.

Поделиться этой страницей