Михайло — Є дві новини, як в класиці. Д...

Є дві новини, як в класиці.

Добрі:
Я написав програму на ноді яка може скрапити юзерів з блюскаю по АПІ.

Погані:
Програма геть повільна. Основний ботлнек - це запити до АПІ та збереження даних в mysql.

Ботлнек в АПІ мені не пофіксати. Залишається 2 варіанти:

1. розпаралелити синхронізацію по воркерам
2. переписати все в раст (і розпаралелити синхронізацію)

Михайло

Якщо там в основному io-bound обчислення (запити в API, запити в БД), то, як ідея, можна спробувати:
- розпаралили за допомогою Promise.all або заюзати async.queue з пакету async
- записувати в базу пачками, для прикладу по 100 записів за один

Сорян, за непрохані поради

Михайло

Все ок, але тільки Promise.all не має нічого спільного з паралельними процесами))

Я зараз читаю за worker threads та child threads в ноді. Це для мене тема нова. Тому поки сам посиджу поміркую. Але, якщо що - я вам напишу 🙂

Yevhenii Hyzyla

Event loop апріорі не може нічого оброблювати парарельно. Це однопотоковий процес.
Всі мікротаски створені промісами виконуються асинхронно і почергово.

Yevhenii Hyzyla

але якщо у вас запит в бд чи на API блкуская, то event loop переключається на іншу мікрозадачу. Якщо ж немає CPU обчислень, то потік переважно буде сидіти і чекати відповідь, а міг виконувати інші проміси

Михайло

Все так як ви написали.
Але я не можу не евейтити проміси які йдуть до бази даних. Бо мені необіхдно знати айдішники юзерів які я записую.

Єдине місце де я думаю може спрацювати Promise.all - це в самому вверху програми, де я запускаю синхронізацію.

Yevhenii Hyzyla

кста, оця зміна має норм пришвидшити, як на мене. замість того, що послідно обробляти буде 100 конкурентних запитів. Можливо syncFollowers чи syncFollows можна ще отимізувати і буде взагалі шик

Михайло

Можливо варіант ще в базу записувати батчами (чи одним запитом), якщо цього ще не робите. Хоча можливо вприається програма у швидкість блускай апі

Михайло

Similar Posts