December 30th, 2014

Парсер и многопоточность

Да, если и допускаются ошибки в реализации на Haskell, то это ошибки самих алгоритмов.
Упёрся в одну тему.
1. Парсер перебирает последовательно категории (свыше 900).
2. В каждой категории порядка 270 страниц.
3. На каждой странице по 40 объектов.
4. 1 страница - 1 транзакция.
5. Последовательный перебор страниц - медленно (7 часов - это 420 минут, 25200 секунд, 20 категорий и 190 тысяч записей).
6. Выбираю по 8 страниц и каждую укладываю в отдельный поток - скорость записи возрастает, но в месте с ней проскакивают сообщения о том, что пул соединений к базе забит. В конечном итоге парсер забивается совсем.
7. Уменьшаю число потоков - оттягивается время для забивания парсера.

Конечно, основная проблема тут в том, что парсинг привязан к вставке в базу.
Распарсили страницу - вставляем в базу. При таком подходе многопоточность себя не оправдывает. Надо копать каналы и передавать через них.

Парсер и многопоточность, часть 2

Отписываюсь по результатам.

  • На реализацию алгоритма ушло больше времени, чем на написание рабочего кода
  • Как и ранее, код компилируется - всё работает так, как надо, пока "изменений" нет, что бы ни говорил vit_r (видимо, сложность проекта пока мелкая, а значит: поживём - увидим).
  • Добавил очереди, теперь страницы парсятся асинхронно, набивая очередь из объектов.
  • Каждые 500 объектов из очереди отгружаются в базу.
  • Скорость парсинга одной категории (270 страниц) возросла: раньше требовалось 15 минут, теперь 1.
  • А общее время парсинга с 13 дней сократилось до 15 часов.

Думаю, чего бы ещё потюнить.

Tags: , ,