Are there currently some outages with the fingerprint API?
Using premium and facing the error "Thread ended with message "Fingerprint error: "Fingerprint with tags Microsoft Windows,Chrome not found 0""" when running scripts.
Параллельная работа puppeteer-with-fingerprints?
-
@UserTrue said in Параллельная работа puppeteer-with-fingerprints?:
Но даже если вам нужны отдельные процессы, то все равно нет смысла для каждого процесса заново инициализировать клиент БАС, достаточно запустить его один раз, а уже потом плодить процессы.
0_О а можно тут поподробнее? Я наверное правда что-то упустил, как можно клиент BaS запустить только один раз что бы потом от него форкать процессы?
P.S. У меня изначально код был на nodejs + puppeteer - web crawler (spider) + сессии, т.е. у каждого свой "userDataDir", и тут я нечаянно наткнулся на фингерпринты от bablosoft + perfectcanvas, мне очень понравилось, тем более что прикрутить его оказалось очень просто с помощью: puppeteer-with-fingerprints. Но вот с параллельной работой у меня трудности возникают :( Хотя вот тут multithreading.js всё крайне просто, но я ж не ищу лёгких путей )))
-
@DevBox said in Параллельная работа puppeteer-with-fingerprints?:
как можно клиент BaS запустить только один раз что бы потом от него форкать процессы
Никак, я не это имел ввиду. Процессы форкать вообще не нужно по идее, как я уже это и писал, nodejs это про асинхронность. Процессы нужны если у вас есть сложные вычисления, которые могут заблокировать event loop, да и это для это уже есть worker threads
-
@DevBox said in Параллельная работа puppeteer-with-fingerprints?:
нет смысла для каждого процесса заново инициализировать клиент БАС, достаточно запустить его один раз, а уже потом плодить процессы.
Я по поводу этого, немного поковырялся в репах puppeteer-with-fingerprints, получается что при:
const { plugin } = require('puppeteer-with-fingerprints');Как раз тот самый клиент стартует?
-
@DevBox вы можете посмотреть тикеты в репозиториях (в том числе закрытые), там подобные вопросы уже обсуждались. На данный момент движок в плагинах устроен так, что вы можете использовать сколько угодно экземпляров браузера асинхронно через промисы и любым другим образом, но тут есть ограничение - параллельные запросы будут частично синхронизироваться между собой, это сделано специально, чтобы избежать кучи других возможных проблем, вроде race condition и так далее. Сам запуск браузера тоже будет синхронизирован, под капотом они будут запускаться последовательно, но дальше вы можете спокойно работать с ними так, как вам угодно.
Если такой вариант не устраивает, вы можете клонировать папку с движком и любым способом (например через несколько процессов) использовать разные папки (см. метод
setWorkingFolder), тогда процесс запуска браузеров и другие специфичные для плагина действия будут выполняться быстрее, но и тут есть минус - лишний движок будет занимать место на диске.Так же обратите внимание на примеры в папке
examplesв каждом репозитории, надеюсь эта информация сможет вам помочь. -
Я сейчас использую метод из examples, а именно: multithreading.js через какое-то время вываливаются ошибки:
UNCAUGHT EXCEPTION: Lock is not acquired/owned by you Error: Lock is not acquired/owned by you at C:\Users\Administrator\Develope\PROC\node_modules\proper-lockfile\lib\lockfile.js:285:43 at LOOP (node:fs:2824:14) at process.processTicksAndRejections (node:internal/process/task_queues:77:11)Всего 10 потоков :(( посоветуйте что делать?
-
@DevBox попробуйте использовать разные папки для потоков, ещё для безопасности можно синхронизировать полностью участок
fetch+launch, например, с помощью этого пакета - https://www.npmjs.com/package/async-lock. -
@DevBox said in Параллельная работа puppeteer-with-fingerprints?:
К чему вы пришли, как лучше запускать параллельно?
BAS стартует, запускает сторонний скрипт, которые генерит для него задания. Далее BAS обрабатывает задания и запускает другой скрипт с параметрами запущенных браузеров(remote-debugging-port).
Последний скрипт делает всю работу по управлению браузерами, логикой, etc.
-
С одним вроде справляешься, новое вылезает 🤦
UNCAUGHT EXCEPTION: read ECONNRESET Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:217:20)Кладёт всё приложение вне зависимости сколько там у тебя потоков и сколько папок :(( пока не нажмёшь ctrl+c
-
@DevBox есть такое решение, хоть и не идеальное:
https://github.com/CheshireCaat/browser-with-fingerprints/issues/13#issuecomment-1793508120
-
Вот где-то тут жёстко виснет, условно навсегда )
-------------------------------- 2024-05-20T12:55:05.768Z: read ECONNRESET Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:218:20) -------------------------------- 2024-05-20T13:05:35.377Z: write ECONNABORTED Error: write ECONNABORTED at afterWriteDispatched (node:internal/stream_base_commons:161:15) at writeGeneric (node:internal/stream_base_commons:152:3) at Socket._writeGeneric (node:net:953:11) at Socket._write (node:net:965:8) at writeOrBuffer (node:internal/streams/writable:564:12) at _write (node:internal/streams/writable:493:10) at Writable.write (node:internal/streams/writable:502:10) at Socket.<anonymous> (C:\Users\Administrator\Develope\PROC\node_modules\browser-with-fingerprints\src\plugin\connector\server\index.js:18:18) at Socket.emit (node:events:520:28) at addChunk (node:internal/streams/readable:559:12) -
@DevBox попробуйте на сам socket повешать обработчик ошибок, видимо client рвет соединение. Но ещё нужно смотреть почему он его рвёт, я сильно не изучал как там все устроено.
-
@UserTrue Я сам сокет не создаю :\ это где-то внутри
node_modules\browser-with-fingerprints\src\plugin\connector\server\index.js:18:18
Т.е. скрипт работает, тупо встаёт, допустим через час я к монитору подхожу, вижу что висит, шлю ему SIGKILL (ctrl + c)
Он вываливает ошибку:-------------------------------- 2024-05-20T20:02:56.118Z: write ECONNABORTED Error: write ECONNABORTED at afterWriteDispatched (node:internal/stream_base_commons:161:15) at writeGeneric (node:internal/stream_base_commons:152:3) at Socket._writeGeneric (node:net:953:11) at Socket._write (node:net:965:8) at writeOrBuffer (node:internal/streams/writable:564:12) at _write (node:internal/streams/writable:493:10) at Writable.write (node:internal/streams/writable:502:10) at Socket.<anonymous> (C:\Users\Administrator\Develope\PROC\node_modules\browser-with-fingerprints\src\plugin\connector\server\index.js:18:18) at Socket.emit (node:events:520:28) at addChunk (node:internal/streams/readable:559:12) -------------------------------- 2024-05-20T20:03:42.856Z: read ECONNRESET Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:218:20)И самое интересное, продолжает дальше работать как ни в чём не бывало )))
Т.е. там где-то внутри соке ждёт без какого-либо таймаута, хрен бы с ним вывалил бы какю-нибудь ошибку, я бы её обработал и пошёл он дальше гулять, так нет, он просто встаёт :(
И это такие свистопляски на AMD EPYC 7351P 16-Core Processor с оперативкой в 256 гиг, я бы ещё понял, если бы я на древнем селероне запускал и он бы так выпендривался. но нет, вполне сносный процессор, чистого chromium он может держать примерно 50-56 потоков. -
@DevBox посмотрю, когда буду обновлять движок у плагинов - не могу сказать причину (сервер всегда стартует на рандомном свободном порту), почему рвется соединения, но постараюсь повторить.
Пока попробуйте это - https://stackoverflow.com/questions/71980181/nodejs-uncaught-econnaborted-socket-exception.
Так же можете до обновления добавить error handling сюда (прямо руками в node_modules), возможно поможет:
-
@DevBox said in Параллельная работа puppeteer-with-fingerprints?:
Т.е. скрипт работает, тупо встаёт
Я когда-то давно смотрел как работает что внутри, если не ошибаюсь, то сделано так, что при наличии любых ошибок посланной команды, скрипт будет висеть вечно. Не проверяется ничего и нигде. Тестов толком тоже нет.
Также есть библиотека на python для удаленного вызова функций из BAS, там сделано также. Офигел в свое время переделывать.
Было даже так, что коннектишься к браузеру, убиваешь браузер из консоли, а скрипт как висел, так и будет висеть, потому что внутри библиотеки архитектурная ошибка логики работы с websocket между скриптом и BAS.
-
@Oyasumi-Punpun , спасибо, попробую
