Перевод текстов
В срочном порядке ищутся владельцы PROMT Internet Translation Server SDK. Понятное дело, что платной версии.
У меня есть предложение о коммерческом сотрудничестве.
Профессиональный парсинг/граббинг/сбор информации
В срочном порядке ищутся владельцы PROMT Internet Translation Server SDK. Понятное дело, что платной версии.
У меня есть предложение о коммерческом сотрудничестве.
В качестве затравки своих Perl навыков предлагаю общественности на рассмотрение Перловый парсер значений ТИЦ.
Код я постарался снабдить большим количеством комментариев, так что разобраться в нем для вас не должно составить проблем.
Также хочу отметить, что данный код я написал не для практического применения, а исключительно в качестве примера многопоточности и ее реализации в Perl.
#!/usr/bin/perl -w # Многопоточный парсер значения ТИЦ # by ParserPro (http://parse.com.ua | http://parserpro.com) # 12/01/2008 use strict; use threads; use threads::shared; use LWP::Simple; use constant BASE_URL => 'http://bar-navig.yandex.ru/u?ver=2&show=32&url='; # базовый адрес откуда будем получать значение ТИЦа use constant MAX_THREADS => 20; # максимальное количество потоков. Можете поставить и больше ;) my $thread_count : shared; # счетчик потоков $thread_count=1; # По умолчанию скрипт принимает 2 аргумента: # - файл с урлами # - имя файла, в который будут записаны значения ТИЦа if(@ARGV != 2) { die "Usage: tyc.pl <urls_file> <output_file>\n"; } open(URLS,'<'.$ARGV[0]) or die "Не могу открыть файл: $! \n"; my @lines; # массив для урлов while (<URLS>) { chop; # убрали переводы строки s/^\s+//; # убрали предшествующие пробелм s/\s+$//; # убрали постшествующие пробелы next unless length; # если после этого длина = 0 перейти к следующей строке push @lines, $_; # запихиваем урлы в большой массив } open(OUTPUT,'>>'.$ARGV[1]) or die "Не могу создать файл: $!\n"; my @proc; # массив потоков my $s = times; # секундомер foreach (@lines) { while ($thread_count > MAX_THREADS) {} # пока количество потоков больше MAX_THREADS ждем push @proc, threads->create(\&getTYC,$_); # запускаем поток $proc[$#proc]->join(); # приатачиваем последний запущенный поток к главной программе } $s=(times-$s)*60; print "Elapsed time: $s seconds\n"; sub getTYC($) { ++$thread_count; # запустили поток my $tycUrl = shift; my $url = BASE_URL.$tycUrl; my $content = get $url; if(defined $content) { if ($content =~ /value\=\"(.*?)\"/) { if ($1 eq '') { print "$tycUrl;!\n"; print OUTPUT "$tycUrl;!\n"; } else { print "$tycUrl;$1\n"; print OUTPUT "$tycUrl;$1\n"; } } else { print "$tycUrl;!!\n"; print OUTPUT "$tycUrl;!!\n"; } } else { print "$tycUrl;!!!\n"; print OUTPUT "$tycUrl;!!!\n"; } --$thread_count; # завершили поток }
У данного кода есть несколько преимуществ:
и ряд недостатков:
Также скрипт не показал себя сильно производительным. На моем компе проверку 100 URL он произвел за 220 секунду, то есть по 2 секунды на адрес - ОЧЕНЬ МЕДЛЕННО! Также удивил тот факт, что такой примитивный скрипт отгрыз около 5 метров оперативной памяти (наверное ты это имел ввиду, SHAman, когда мы с тобой говорили про потоки). Притом при создании нового потока объем используемой памяти увеличивался. Со временем память высвобождалась. Но само поведение меня потоков меня напрягало.
Так что пробуйте скрипт у себя. Говорите о результатах, делитесь опытом, так сказать. А для себя я еще раз убедился, что PERL POE будет оптимальным решением для моих задач!
Удачи!
Постоянно читаю отклики разработчиков высоконагруженных приложений (коими парсеры и грабберы также являются) и просто стараюсь отслеживать что происходит в мире программирования и понемногу начинаю приходить к мысли, что при разработке самых крупных проектов надо отходить от скриптовых языков программирования и обращаться ко всяким там C++, C# и им подобным.
И по этому поводу хочу спросить, что думаю мои подписчики. Кто что пробовал? Какие тесты видели на эту тему? Какие шишки набили? Где многопоточность лучше показала себя? Что успели попробовать? Не молчите - выскажитесь! Поделитесь своим опытом, а другие поделятся с вами. И так все станут хоть на грамм умнее и эффективней!
Спасибо!
Как я уже отмечал ранее, базы данных в последнее время становятся узким местом для приложений, предназначенных для парсинга, граббинга и сбора информации. Это связано с тем, что сейчас практически любой движок построен на основе четырех десятков таблиц и тучи сложных запросов, а когда на одном хостинге таких движков находится штук 100, то многого просить от БД не приходится, даже с учетом того, что MySQL (а чаще всего хостеры используют именно его) – чертовски быстрая штука при правильной настройке.
Эта проблема стала для меня очень остро ставать, когда мои клиенты начали жаловаться, что разработанные мною парсеры не делают своей работы. Я стал разбираться и пришел к выводу, что с подобными проблемами даже сложнее бороться, чем с тем же segfault.
Например, на одном из хостингов клиента при запуске парсера через 20-30 минут MySQL выдавал «MySQL server has gone away» и после этого вся далее собранная информация уходила в трубу. Также не редкими были проблемы, когда MySQL просто умирал от нагрузок (понятное дело, что не со стороны моих парсеров). Я начал искать решение данной проблемы. Пробовал даже разработать систему отложенного выполнения запросов, ставил таймауты, когда не мог выполнить запрос. В общем, думал я над этой проблемой и пришел к выводу, что проще всего всю информацию записывать в CSV или SQL dump файл, а по окончании парсинга одним запросом выгружать это в БД.
У этого решения есть ряд преимуществ:
Но также есть и некоторые недостатки у подобного подхода:
То есть данное решение стоит применять, например, в ночных парсерах для больших массивов данных. Так что советую людям, которые собирают информацию взять данную идею на заметку. Конечно же эти проблемы не касаются тех, у кого стоит с 10 выделенных серверов на гигабитном инете
Хочу порадовать своих иностранных (западных) клиентов, потому что теперь им не придется звонить по Skype и задавать мне миллион вопросов. Потому что специально для них я запускаю англоязычный сайт ParserPro. В ближайшее время я заполню и его контентом и буду вести блог и на английском языке.
Выходим на интернациональный уровень! ![]()
Уважаемые потенциальные клиенты!
В связи с огромной загруженностью по проектам на парсинг/граббинг/сбор информации с сегодняшнего дня и по 15.02.2008 я не буду брать дополнительные проекты. Прошу извинить за неудобства.
P.S. На поддержке уже существующих пользователей данное заявление никак не отразится.
Очень часто при создании сайтов необходимо собрать какую-то галерею тематических картинок или сделать что-нибудь на основе этих тематических картинок. Например, на сайте про футбольную команду всегда будут присутствовать фотографии ее футболистов и их матчей. И при создании подобного сайта возникает задача сбора этих самых фотографий и картинок.
Именно для таких целей я разработал граббер картинок с Яндекс.Картинки.
Возможности граббера:
Стоимость данного граббера: 25 $.
Комментарии разработчика: граббер очень неплохой. Написан на основе открытой библиотеки MultiCurl, что поможет вам легко сопровождать и модернизировать код под ваши нужды. Если с умом подойти к граббингу и поставить нормальные интервалы, то можно без проблем собрать все картинки из выдачи. Также плюсом является то, что разработка не использует базы данных, так как последнее время именно они становятся узким местом на серверах. Если будут вопросы - вы всегда можете обратиться ко мне по адресам, указанным в контактах.
Удачи!
В своем предыдущем посте я обещал своим клиентам, что в 2008 году я приступлю к разработке новой платформы и поэтому мне хотелось бы немного о ней рассказать. Думаю, что профи в области парсинга и граббинга информации это будет интересно.
Как вы уже могли видеть, основным языком, которым я пользовался ранее для разработки парсеров и грабберов был PHP. Язык на удивление простой, хорошо документированный и достаточно мощный. На начальных порах, когда в месяц обрабатывалось порядка 500к-800к страниц мне его было достаточно, но с увеличением объемов я начал ощущать, что он не совсем подходит для выполнения подобной работы. Что меня в нем не устроило:
Одним словом, PHP ввел достаточно много ограничений в мою работу, обход которых вводил другие ограничения и так до бесконечности. Я не преуменьшаю достоинств PHP, но для задач парсинга и граббинга информации он не достаточно гибок.
Поэтому я решил обратить взоры на некогда мной любимый Perl. Он быстрее работает с регулярными выражениями, что является основой любого парсера, более умно управляет памятью и имеет намного более гибкий синтаксис, что помогает решать сложные задачи простыми методами. Поэтому в этом году я начну переносить всю свою платформу именно на Perl.
Конечно же постоянные рабочие проекты и проекты “под заказ” будут крутиться на PHP, но все новые проекты я буду стараться реализовать на новой платформе. Я надеюсь получить увеличение производительности на 40-70% в результате переноса.
Так что лучше, выше, быстрее!

Поздравляю всех своих клиентов, подписчиков, партнеров и друзей с Новым Годом. Я уверен, что в этом году вы добились многого, но я верю, что Новый Год откроет перед вами бесчисленные горизонты возможностей и вы достигнете всех поставленных целей и осуществите свои самые заветные мечты.
Отдельно я хотел бы поздравить своих клиентов, которые доверили свои проекты моим рукам и оставили столь приятные отзывы о моей работе на Weblancer.net и Webmoney.ru. Спасибо вам огромное! Обещаю, что Новый Год мы с вами встретим с новой парсинг-платформой, которая позволит собирать и обрабатывать миллионы записей в сутки.
Поздравляю всех! УДАЧИ!
P.S. До 6ого января я буду в отпуске, поэтому прошу всех моих великолепных заказчиков немного потерпеть. Когда я вернусь с новыми силами я удивлю вас своей производительностью! ![]()
Как-то странно упала посещаемость моего сайта. Притом упала в разы. Видно Гугл и Яндекс наказывают меня за то, что я с них ссылки собирал :)))