Скорость работы не увеличивается, при увеличении потоков.

  • Автор темы Автор темы clocky
  • Дата начала Дата начала

clocky

Client
Регистрация
26.09.2019
Сообщения
400
Реакции
72
Баллы
28
Друзья, проблема в следующем, есть парсер, на гет запросах, без браузера. По сути, он просто парсит DOM страницы и дальше regex'ами достает нужную информацию, какого то особенного доп кода нету, но достаточно много regex'ов. около 120. Единственная вещь, что если запускать в ПМ, то порой если какой-то инфы нету на сайте, то этот regex довольно долго прогружает. В конце все записывается в таблицу на компьютере.

Вопрос, 10 потоков работают лучше, чем 40. Компьютер вывозит, загрузка 40% максимум. В чем может быть проблема? Спасибо. Зенка последняя.
 
Друзья, проблема в следующем, есть парсер, на гет запросах, без браузера. По сути, он просто парсит DOM страницы и дальше regex'ами достает нужную информацию, какого то особенного доп кода нету, но достаточно много regex'ов. около 120. Единственная вещь, что если запускать в ПМ, то порой если какой-то инфы нету на сайте, то этот regex довольно долго прогружает. В конце все записывается в таблицу на компьютере.

Вопрос, 10 потоков работают лучше, чем 40. Компьютер вывозит, загрузка 40% максимум. В чем может быть проблема? Спасибо. Зенка последняя.
1. Что в вашем понимании вывозят лучше? Мы не можем знать, что вы там вывозите и какой процесс бот делает.
2. Возможно проблема в интернете.
3. Возможно проблема в прокси.
4. Возможно проблема в кривом написанном боте:
- Работа с ексель или еще с каким файлом - возможно большие потоки ставят запись в файл в очередь в результате зависания
- и т.д.

Хотя бы пример покажите, например видео, как что работает, какие результаты на 10 ти потоках, какие на 40. У каждого свои понимания вывозения.
 
Друзья, проблема в следующем, есть парсер, на гет запросах, без браузера. По сути, он просто парсит DOM страницы и дальше regex'ами достает нужную информацию, какого то особенного доп кода нету, но достаточно много regex'ов. около 120. Единственная вещь, что если запускать в ПМ, то порой если какой-то инфы нету на сайте, то этот regex довольно долго прогружает. В конце все записывается в таблицу на компьютере.

Вопрос, 10 потоков работают лучше, чем 40. Компьютер вывозит, загрузка 40% максимум. В чем может быть проблема? Спасибо. Зенка последняя.
Закрузка 40% еще ни о чем не говорит. Вы правильно делаете, что смотрите на эффективность работы. Найдите оптимальное значение для себя. Кстати какой процессор?
 
Закрузка 40% еще ни о чем не говорит. Вы правильно делаете, что смотрите на эффективность работы. Найдите оптимальное значение для себя. Кстати какой процессор?
Core i5-3570S 3.1ghz, нагрузки на сеть нету, процессор и память почти свободны) Хотелось бы видео записать, но боюсь это трилогия получится) Я тут просто с секундомером все засекаю, и больше 8 потоков особых изменений не вижу. Дело точно не в прокси, скорости интернета, в общем не в сети. Нагружать тоже особо не должен, я думаю может какая защита срабатывает?
 
если 10 потоков работают лучше 40, то скорее всего надо оптимизировать шаблон, то что все сделано на регексах - это плохо
все тормоза изза того что код видимо огромный и регексы охеревают от поиска по коду
если это все переписать на xpath то скорее всего скорость увеличится в разы

или экрань основной код перед региксами, НО лучше xpath
 
  • Оценить
Реакции: Roman48 и clocky
если 10 потоков работают лучше 40, то скорее всего надо оптимизировать шаблон, то что все сделано на регексах - это плохо
все тормоза изза того что код видимо огромный и регексы охеревают от поиска по коду
если это все переписать на xpath то скорее всего скорость увеличится в разы

или экрань основной код перед региксами, НО лучше xpath
Похоже на то, дело в том, что если нужный реджекс присутствует, то быстро проходит, но если его нету, он видимо обрабатывает всю страницу, поэтому получается дольше. Скорее всего Вы правы. Спасибо за помощь. Хотел переписать с условиями, чтобы всегда был только нужный реджекс, для каждой категории, но слишком уж много чего перелопатить надо, а для того, чтобы спарсить один раз 20к объявлений а потом в день по 100-200 парсить, не вижу смысла особо.

Всем спасибо!
 
а загрузка винчестера какая? А темпеература процессора? Может, он плохо охлаждается и не идет больше сорока процентов, у меня было такое
 
Проц хороший, но уже староват. Чудес от него ждать не стоит.
нагрузки на сеть нету, процессор и память почти свободны)
Знаешь я как делал. Брал секундомер и замерял ключевые моменты в шаблоне, регулярка, запись в список, чтение. И потом уже проводил анализ.
 
Проц хороший, но уже староват. Чудес от него ждать не стоит.

Знаешь я как делал. Брал секундомер и замерял ключевые моменты в шаблоне, регулярка, запись в список, чтение. И потом уже проводил анализ.
А что "Трассировка проектов" уже неработает ??? https://zennolab.com/wiki/ru:trace
 
А что "Трассировка проектов" уже неработает ??? https://zennolab.com/wiki/ru:trace
Она работает. Но как инструмент для аналитики жуть какая не удобная. А секундомер сразу в лог выводишь и видно. В общем трасстровка весьма специфичная фича, идея хороша, но реализована не до конца. Взять даже простой пример, получить id кубика что бы найти его в трассировке, если бы это было реализовано, то трассировка была бы вдвойне полезней.
 
Она работает. Но как инструмент для аналитики жуть какая не удобная. А секундомер сразу в лог выводишь и видно. В общем трасстровка весьма специфичная фича, идея хороша, но реализована не до конца. Взять даже простой пример, получить id кубика что бы найти его в трассировке, если бы это было реализовано, то трассировка была бы вдвойне полезней.
Она была б класная - если б ее можно было подгрузить к проекту и запусстить на выполнение - и в реальности посмотреть де что пинается (даже без данных в проекте - просто увидеть где и какой кубик тормозит проект)
 
  • Оценить
Реакции: Mikhail B.
Часто тоже посылаю всех на вики с трейсингом, но вот когда сам сел оптимизировать свои старые комбайны (а там обычно горы костылей), то задумался и создал шаб-анализатор. Принцип такой:
1. Включаем трассировку на исследуемом шаблоне.
2. Запускаем наш шаб в обычном режиме работы, допустим в 1…10 потоков.
3. Останавливаем работу шаба через час и файлы трассировки переносим в папку шаблона-анализатора «\Zenno_Tracer\Input\1_Good\»
4. Запускаем наш шаб в режиме работы «под нагрузкой» где он «тормозит», допустим в 50…200 потоков.
5. Останавливаем работу шаба через час и файлы трассировки переносим в папку шаблона-анализатора «\Zenno_Tracer\Input\2_Bad\»
6. Запускаем шаблон-анализатор. Он посчитает среднее время выполнения для каждого кубика, сравнит их в обеих режимах и на выходе получим типа такую таблицу, из которой я понял что наибольшие потери на кубике «сохранения профиля» ибо в многопотоке на исследуемом браузерном шабе он очень тупил:
trace.png

Исходники будут в ближайшем конкурсе шаблонов :-).
 

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