Многопоток во многопотоке, логика

JanCarlo

Client
Регистрация
04.03.2018
Сообщения
358
Благодарностей
40
Баллы
28
Ребят, нужна помощь!

Видимо я заранее не продумал этот момент и запилил его. Шаблон очень большой.
Столкнулся я с проблемой медленного парсинга во многопотоке.

На компе есть пару сотен папок в которых есть текстовики с ключевыми запросами. На каждую папку своя тематика и соответственно везде ключи разные.
Шаблон создает текстовик с директориями на эти списки с ключевиками - это в один поток буквально одна секунда.
Далее, уже во многопотоке, шаблон берет ссылки на эти списки с ключевиками и начинает из списков брать ключевые слова, и по каждому ключевому слову парсит контент.
Поясняю - к примеру в 10 потоков - шаблон взял 10 ссылок на текстовики с ключевыми словами, загрузил эти ключевые слова во внутренний список, и на каждый ключ начинается парсинг. Условно говоря 10 потоков = парсинг 10 ключей. В принципе все бы ничего но, проблема в том, что этих ключевых слов может быть 500 а может быть и 7000. Если парсить в один поток 1500 ключей, это примерно 30 часов =( парсинг идет на вэбе обходя примерно 25 страниц ПС на каждый ключ потому и выходит так долго. Перепиливать на гет запросы крайне затруднительно на данный момент.

Вопрос - как переделать логику так, что бы шаблон, К ПРИМЕРУ, в ПЯТЬ потоков взял ПЯТЬ списков с ключевиками, и когда начался парсинг каждого списка - каждый поток разделялся к примеру еще на 5 потоков что бы одновременно парсить контент на пять ключей из одного списка?

Поясняю - Шаблон берет список ссылок на списки ключей, далее берет одну ссылку на один список, в один поток, как получил ключи (которых к примеру 3000) поток разделился еще на 5 ПОДпотоков что бы эти ключи быстрее пропарсить.

Есть идеи как это реализовать? Если слишком замудренно, может у кого есть более простое решение?
По возможности в будущем переведу на запросы, но сейчас пока некогда.
 

Phoenix78

Client
Read only
Регистрация
06.11.2018
Сообщения
11 789
Благодарностей
5 721
Баллы
113
по любому логически надо разделять.
мне кажется самое простое в данной ситуации завести табличку с ходом выполнения. типа id потока, id_1 подпроекта, id_2 подпроекта, id_3 подпроекта и тд.
запустился поток, анализирует в табличке записи, если все заполнены, создает новую запись с уникальным id потока. и пошел шерстить от 0 до 500
следующий поток находит незаполненную id предыдущего и пристраивается в id_1 подпроекта, проставляет метку и шерстит от 501 до 1000.
по результатам работы можно метки ставить, типа id_1_1_ок , id_1_2_ok, ... или если не выполнил выставлять error
естественно таблицу надо жестко лочить что бы пересечений не было. и очистку тоже делать иногда надо :-)
а да естесно надо переделать шаблон что бы первоначальные данные зависили от id, можно прописать в первоначальном формировании id и добавления записи, там же где нибудь и воткнуть все нужные записи.
 
  • Спасибо
Реакции: JanCarlo

zarufakis

Client
Регистрация
22.03.2019
Сообщения
1 743
Благодарностей
1 137
Баллы
113
может у кого есть более простое решение?
Не думал весь этот "замудр" в базу данных перенести? Полюбасу из нее выборка будет происходить на порядки быстрее.
 
  • Спасибо
Реакции: JanCarlo

JanCarlo

Client
Регистрация
04.03.2018
Сообщения
358
Благодарностей
40
Баллы
28
Не думал весь этот "замудр" в базу данных перенести? Полюбасу из нее выборка будет происходить на порядки быстрее.
Да думал, боюсь этим не сильно много времени сэкономиться так как большее количество времени уходит на парсинг самих ключей, а ключей очень много. Надо как то организовать многопоток, в котором внутри во многопотоке ключи будут парситься одновременно несколько штук из одного списка. С другой стороны, парсинг 300 ключей дал мне текстовки на 50мб, больше 45000 строк текста. Надо ли одно парсить все 5000-7000 ключей - вот хз
 

zarufakis

Client
Регистрация
22.03.2019
Сообщения
1 743
Благодарностей
1 137
Баллы
113
Да думал, боюсь этим не сильно много времени сэкономиться так как большее количество времени уходит на парсинг самих ключей, а ключей очень много. Надо как то организовать многопоток, в котором внутри во многопотоке ключи будут парситься одновременно несколько штук из одного списка. С другой стороны, парсинг 300 ключей дал мне текстовки на 50мб, больше 45000 строк текста. Надо ли одно парсить все 5000-7000 ключей - вот хз
Чувак, тебе реально путь к mySQL, я других вариантов не вижу))
 

Кто просматривает тему: (Всего: 1, Пользователи: 0, Гости: 1)