Comments 13
Я для асинхронной загрузки кучи страниц использовать модуль async и метод async.map.
На Node.js очень удобно парсить… Но, собственно, это и единственное, что на нём делается действительно удобно. Например, сферический пример №1 из статьи не сможет обработать redirect, придётся вставлять рекурсию:
Да и к тому же работать с кукисами приходится вручную, а все мало-мальски сложные странички их проверяют (сервер всегда готов выслать дулю вместо странички, если что не так). И совсем уж плохо, когда часть контента страницы формируется с помощью Javascript.
Всё сильно упрощается при использовании фреймворка node-webkit, на котором мне даже удалось написать универсальную качалку статей (sciencedirect, springerlink, ACS и RSC), но по граблям пришлось потоптаться солидно, даже исключая баги самого NWK и ограничиваясь лишь Node.js-частью.
Самое противное в этой ноде то, что она о-очень неохотно убивает объекты — открытые файлы, сокеты и т.д.
Например, построив простейшую процедуру закачки столкнулся с тем, что закачивается… ровно пять файлов! После чего скорость закачки падает до одного файла в минуту. Оказывается, нода не прибивает сокеты после request'а, а на каждый запрос создаётся новый сокет. Частично проблема решилась через увеличение лимита сокетов и отключение Agent'а в опциях запроса, полностью же удалось победить зловредный фреймворк лишь отловом события подключения, запоминанием socket-объекта во временной переменной и последующим вызовом socket.destroy().
И вот там полно таких проблем, возникающих буквально на пустом месте. Например, файлы после вызовов end() и close() всё равно числятся открытыми и, к примеру, не могут быть удалены сторонними программами, пока фреймворк активен (а всё потому, что работа со stream'ами там организована мягко говоря не очевидным способом).
if ( [301, 302].indexOf(res.statusCode) > -1 ) {
download(res.headers.location);
return;
}
Да и к тому же работать с кукисами приходится вручную, а все мало-мальски сложные странички их проверяют (сервер всегда готов выслать дулю вместо странички, если что не так). И совсем уж плохо, когда часть контента страницы формируется с помощью Javascript.
Всё сильно упрощается при использовании фреймворка node-webkit, на котором мне даже удалось написать универсальную качалку статей (sciencedirect, springerlink, ACS и RSC), но по граблям пришлось потоптаться солидно, даже исключая баги самого NWK и ограничиваясь лишь Node.js-частью.
Самое противное в этой ноде то, что она о-очень неохотно убивает объекты — открытые файлы, сокеты и т.д.
Например, построив простейшую процедуру закачки столкнулся с тем, что закачивается… ровно пять файлов! После чего скорость закачки падает до одного файла в минуту. Оказывается, нода не прибивает сокеты после request'а, а на каждый запрос создаётся новый сокет. Частично проблема решилась через увеличение лимита сокетов и отключение Agent'а в опциях запроса, полностью же удалось победить зловредный фреймворк лишь отловом события подключения, запоминанием socket-объекта во временной переменной и последующим вызовом socket.destroy().
И вот там полно таких проблем, возникающих буквально на пустом месте. Например, файлы после вызовов end() и close() всё равно числятся открытыми и, к примеру, не могут быть удалены сторонними программами, пока фреймворк активен (а всё потому, что работа со stream'ами там организована мягко говоря не очевидным способом).
Цитата из официального репозитория: «Request is designed to be the simplest way possible to make http calls. It supports HTTPS and follows redirects by default.» Должен поддерживать редирект — не все так плохо. Ну насчет кукисов вообщем-то они стандартные можно от своего браузера вписать + jar опцию чтобы он запоминал их, но я просто брал из своего браузера при посещение сайта и копировал в куки агента.
Насчет сокетов у меня конечно на всех серверах стоит максимум открытых соединений, поэтому никогда в это не упираюсь, но вроде работает и в долгом режиме оно все, может и с неохотой но убивает Garbage Collector'ом. Так что 5 сокетов видимо ему просто мало чтобы разогнатся — не считает наверное garbage collector своим долгом, но вообще там можно поставить ограничение на количество одновременных агентов(у реквеста опять же).
Насчет сокетов у меня конечно на всех серверах стоит максимум открытых соединений, поэтому никогда в это не упираюсь, но вроде работает и в долгом режиме оно все, может и с неохотой но убивает Garbage Collector'ом. Так что 5 сокетов видимо ему просто мало чтобы разогнатся — не считает наверное garbage collector своим долгом, но вообще там можно поставить ограничение на количество одновременных агентов(у реквеста опять же).
Просто так в лоб написать парсер с Request не получится. Он не умеет работать, например, с win-1251
Есть еще дико удобный npmjs.org/package/crawler
Правда, с производительностью у него не очень, как мне кажется.
Правда, с производительностью у него не очень, как мне кажется.
pastebin.com/NvGcvPwq
сервер требует(хз зачем видимо такая защита) user-agent. Я изначально подумал что без хоста не разроучивает до конца(но оказалось и без хоста это прекрасно живет). Так что просто дополнительным параметром передал user-agent в header. Вообще коненчо нужно брать header'ы браузера и пытаться их пробовать на других страницах, если такие проблемы возникают.
сервер требует(хз зачем видимо такая защита) user-agent. Я изначально подумал что без хоста не разроучивает до конца(но оказалось и без хоста это прекрасно живет). Так что просто дополнительным параметром передал user-agent в header. Вообще коненчо нужно брать header'ы браузера и пытаться их пробовать на других страницах, если такие проблемы возникают.
Sign up to leave a comment.
Пишем парсер на NodeJS