?

Log in

No account? Create an account
 
 
28 January 2017 @ 01:01 pm
Web crawler hangs  
Our web crawler hanged. Again.
It looks like it hangs with the frequency of about 1 hang per 1 million web page downloads.
Does not timeout. Does not crash. Just hangs.
Fortunately, other threads in our PostJobFreeService keep running.
(Until AngleSharp HTML parser would crash the whole PostJobFreeService on some weird HTML page, of course.)

Unfortunately, crawler hang is not reproducible: the same page can be downloaded without any problems on the next attempt. Or just in a browser.
But once in 1M downloads something weird happens: our crawler successfully passes HTTP handshake with the remote web server (so no HTTP connection timeout), but then hangs.

For our crawler we are using standard HttpWebRequest class from .NET framework.
Should we crawl with something else?

Or is it inevitable that web crawler would hang eventually and our watchdog should simply restart corresponding thread?

Discussion in Livejournal: http://dennisgorelik.livejournal.com/124693.html

Originally posted at: http://dennisgorelik.dreamwidth.org/122942.html
Tags: , , ,
 
 
 
Сисадмин-любительulrith on January 28th, 2017 06:53 pm (UTC)
Венда, .NET - вот уж и правда wtf :)
You should use industry standard solutions in Linux universe...
provokatorzprovokatorz on January 28th, 2017 10:37 pm (UTC)
Linux - это следующий шаг развития. :)
Dennis Gorelikdennisgorelik on January 29th, 2017 12:27 am (UTC)
Может ты ещё и C# предложишь при переезде на linux на что-то поменять?
provokatorzprovokatorz on January 29th, 2017 12:33 am (UTC)
Я думал ты заметишь смайлик в конце.
"... а получилось как всегда"
Dennis Gorelikdennisgorelik on January 29th, 2017 12:49 am (UTC)
Что именно получилось "как всегда"?
Dennis Gorelikdennisgorelik on January 29th, 2017 12:38 am (UTC)
Are you implying that Linux tools would have less bugs?
Сисадмин-любительulrith on January 29th, 2017 07:27 am (UTC)
Definitely!
That's why they're used so widely over the world for network/web/mail/etc applications.
Dennis Gorelikdennisgorelik on January 29th, 2017 10:36 am (UTC)
1) Microsoft tools are also widely used.

2) If switching to Linux - are you suggesting to keep C# or switch to another language?

3) What about SQL Server - switch to PostgreSQL while transitioning to Linux?
Сисадмин-любительulrith on January 29th, 2017 11:44 am (UTC)
1. It's only 11.6% if we talk about web-server stats

2. I'm not a developer but I can suppose you should use Python or something more progressive like Ruby

3. It depends of your project complexity. I'm pretty sure you'll be able to get everything you need from MySQL at the moment
Dennis Gorelikdennisgorelik on January 29th, 2017 12:24 pm (UTC)
> 1. It's only 11.6%

Which is #3 among multiple options.

> you should use Python or something more progressive like Ruby

C# is more progressive than even Ruby.
Besides, what are you suggesting to do with our existing C#/ASP.NET codebase?

> I'm pretty sure you'll be able to get everything you need from MySQL at the moment

Even our existing T-SQL source code?

Yes, you are not a developer
:-)
Сисадмин-любительulrith on January 29th, 2017 12:30 pm (UTC)
Okay, you can keep suffering from your bugs, no prob :)
Dennis Gorelikdennisgorelik on January 29th, 2017 12:46 pm (UTC)
Are you implying we would have less bugs if we rewrite our code in Python or Ruby?

:-)
Сисадмин-любительulrith on January 29th, 2017 01:14 pm (UTC)
Less bugs which you can't understand or reproduce - indeed
Dennis Gorelikdennisgorelik on January 29th, 2017 02:43 pm (UTC)
Unfortunately bugs like these happen on all development platforms...
occam_agaoccam_aga on January 28th, 2017 07:30 pm (UTC)
Dennis Gorelikdennisgorelik on January 29th, 2017 12:45 am (UTC)
Huh.
Did you try it yourself?

How many pages did it process for you so far?
Did it hung?

There is an opinion that crawlers are inherently unreliable:
http://dennisgorelik.livejournal.com/124693.html?thread=2206741#t2206741
occam_agaoccam_aga on January 29th, 2017 05:28 pm (UTC)
I did try it myself, about five years ago. Even got the perf numbers, but totally forgot what they were and they are irrelevant by now anyway.

Tried to make a people search engine which would process requests like "find c# developers in Seattle with more than 5 years experience, willing to switch job"

The sequence of making a crawler was:
1) Started writing my own bot
2) Did some research and found existing Abot
3) Did more research and found that entire Internet is available for free in a parsed form somewhere in Amazon
Dennis Gorelikdennisgorelik on January 30th, 2017 12:02 am (UTC)
> 2) Did some research and found existing Abot

Did you download more than a million pages with Abot in your research?

> 3) Did more research and found that entire Internet is available for free in a parsed form somewhere in Amazon

Do you mean this:
---https://aws.amazon.com/marketplace/pp/B00FY56ATG
Crawlbot allows you to apply either our Automatic APIs or your own Custom API to intelligently extract structured data from an entire site.
---
?
occam_agaoccam_aga on January 30th, 2017 01:38 am (UTC)
Dennis Gorelikdennisgorelik on January 30th, 2017 03:35 am (UTC)
Thank you - we'll review if it makes sense to use Common Crawl on AWS.

However it is a little bit stale dataset. Amazon refreshes it only once per month.

Edited at 2017-01-30 03:35 am (UTC)
Dennis Gorelikdennisgorelik on January 30th, 2017 03:37 am (UTC)
Did you actually try to use Common Crawl on AWS yourself?
occam_agaoccam_aga on January 30th, 2017 04:04 am (UTC)
yes
Dennis Gorelikdennisgorelik on January 30th, 2017 09:07 am (UTC)
Common Crawl on AWS
How many queries did you send to Common Crawl on AWS?

Was it useful to your project?
Христофор Арьеф: pic#125704228freeborn on January 28th, 2017 08:02 pm (UTC)
Дебаггер приатиачить или крашдамп снять нельзя?
Dennis Gorelikdennisgorelik on January 29th, 2017 12:28 am (UTC)
Может быть и можно. Но нужно сначала научиться это делать.
С чего начать и сколько времени подобное исследование займёт?
Yaturkenzhensirhiv - a handheld spyyatur on January 28th, 2017 11:04 pm (UTC)
Я думаю, задачу нужно решать кардинально. Кроулеры будут падать, зависать, сжирать всю память... Я бы завел какую-нибудь очередь (Rabbit MQ?), куда складываются адреса, которые надо прокроулить. И десяток процессов-кроулеров (НЕ потоков, а именно процессов), которые по этой очереди лазят. И процесс-сторож, который следит за тем, что если кто-то их кроулеров не отвечает на сигналы, то убить и перезапустить. Возможно, сделать кроулеры 32-битными, чтобы не могли сожрать всю память.
Dennis Gorelikdennisgorelik on January 29th, 2017 12:25 am (UTC)
> Кроулеры будут падать, зависать, сжирать всю память...

Откуда ты знаешь, что эти проблемы с краулерами неизбежны?

> Rabbit MQ?

Почему бы не обычный SQL server?

> И десяток процессов-кроулеров

Мы пока что и один поток полностью не загружаем, чтобы нас вдруг веб сервера банить не начали.

> И процесс-сторож, который следит за тем, что если кто-то их кроулеров не отвечает на сигналы, то убить и перезапустить.

А убивать потоки вместо процессов нельзя?
Yaturkenzhensirhiv - a handheld spy: Веселый носорогyatur on January 29th, 2017 12:42 am (UTC)
> Откуда ты знаешь, что эти проблемы с краулерами неизбежны?

Из опыта. Если сделать что-то миллион раз с разными данными, то рано или поздно наткнешься на баг. Собственно, ты это очень хорошо продемонстрировал своими жалобами.

> Можно и sql сервер. Но там таблицы. Превращать их в очередь задач придется вручную. А в rabbitmq уже сразу очередь.

> А убивать потоки вместо процессов нельзя?

Можно. Но процессы более надежны - если кроулер и сторож в одном процессе, то у кроулера намного больше шансов умереть, прихватив с собой на тот свет весь процесс вместе со сторожем. Например через stack overflow.


Dennis Gorelikdennisgorelik on January 29th, 2017 01:03 am (UTC)
> рано или поздно наткнешься на баг

Так ведь эти баги чинятся.

Вот occam_aga https://www.nuget.org/packages/Abot/ предлагает.
Думаешь там эти баги не починены?

> в rabbitmq уже сразу очередь.

А для SQL Server у нас уже есть хорошие заготовки для создания очередей.
И отлично интегрируется с остальными данными и сервисами, которые уже используют SQL Server.
И не нужно устанавливать дополнительный компонент.

Ты сам использовал rabbitmq на проекте, который уже использует какую-нибудь базу данных?
Стоил ли rabbitmq дополнительной конфигурационной сложности в проекте?

> прихватив с собой на тот свет весь процесс вместе со сторожем

Когда такое произошло с парсером, Windows Server перестартовал весь процесс. Каждые ~полторы минуты в течение трёх часов (пока не починили).
Понятно, что желательно, чтобы остальные сервисы не падали вместе с краулером.
Но если это происходит очень редко, то можно.
Поддерживать разные процессы - это дополнительная головная боль при конфигурации и deployment проекта.

Edited at 2017-01-29 01:06 am (UTC)
Yaturkenzhensirhiv - a handheld spyyatur on January 29th, 2017 02:41 am (UTC)
> А для SQL Server у нас уже есть хорошие заготовки для создания очередей.

Да пожалуйста, я всего лишь высказываю идеи.

> Стоил ли rabbitmq дополнительной конфигурационной сложности в проекте?

Скорее да, чем нет. Он оптимизирован под определенный тип задач, база - под другой. В принципе все можно хоть на CSV файлах делать или даже просто на дисковых секторах, но обычно использование инструментов, оптимизированных под стоящую задачу, обходится дешевле и приносит меньше граблей.

> Думаешь там эти баги не починены?

Уверен, что там есть еще :)

> Поддерживать разные процессы - это дополнительная головная боль

А ловить баги - это не боль? Я предлагаю признать наличие багов неизбежным и сделать так, чтобы вред от них не был фатальным. Не парсится данный веб сайт - ну и хрен с ним, пишем в лог и идем дальше. Но я ни в коем случае не настаиваю - это ваш проект и ваши деньги.





Edited at 2017-01-29 02:54 am (UTC)
Dennis Gorelikdennisgorelik on January 29th, 2017 03:11 am (UTC)
>> rabbitmq
> оптимизирован под определенный тип задач, база - под другой

Сколько очередей вы организовали на этом проекте?
Нужно ли было делать backup данных этих очередей?
Как вы мониторили состояние этих очередей (длину, время задержки)?
Деплоили ли вы эти очереди на отдельный сервер или на тот же, где уже работала база данных?
Сколько операций в секунду обрабатывали эти очереди?

> Уверен, что там есть еще :)

Вопрос в том, где больше багов - в том коде, который мы уже используем, или в том коде, который придётся написать и конфигурационном и deployment процессах, который придётся поддерживать для того, чтобы убивать подвисшие сервисы.

> А ловить баги - это не боль?

Конечно боль. Но ловить баги придётся в любом случае. С вынесением краулера в отдельный процесс поменяется лишь срочность их отлова. Но усложнится deployment. Который, кстати, нужно выполнять регулярно, в отличие от редких багов, которые нужно фиксить лишь эпизодически.

> Но я ни в коем случае не настаиваю

Зря не настаиваешь.
Это же взаимное обучение.
И самореклама.