ParserPro

Завершил работу над новым парсером статистики запросов Яндекс.Директа. Думаю данный скрипт может пригодится господам оптимизаторам.

Основные возможности парсера:

• парсинг с аккаунта
  Процесс парсинга происходит после входа в аккаунт Яндекса, что позволяет парсить больше запросов
• управление глубиной парсинга
  Есть возможность управлять глубиной парсинга как посредством указания максимального количества обрабатываемых страниц, так и путем указания минимального значения
• количества показов в месяц.
• управление интервалами между запросами
• возможность сохранять число запросов
• возможность генерировать результат парсинга в виде HTML документа
• возможность генерировать результат парсинга в виде CSV (Excell) документа
• возможность работы через прокси (как через открытые, так и через прокси, требующие авторизации)
• управление форматом выдачи результат через конфигурационные файлы
  Выдача парсера может выглядеть и как «запрос;количество_кликов\n», так и как «запрос[количество_кликов]||…». Все это очень просто настраивается через конфиги. В результате чего вы можете подключить результаты парсинга к любому другому инструментарию.
• интерактивная папка Inbox для удобной работы с результатами парсинга
  Ее вид вы можете увидеть на скриншоте парсера.
• технология «Запуск с последнего запроса», которая позволяет в случае бана или обрыва связи запустить процесс парсинга не с самого начала, а с места его завершения

Также в комплекте к парсеру идет документация по установке и использованию.

На скриншоте вы можете увидеть интерфейс парсера.

Стоимость парсер: 65 $

Новые версии программы и исправления ошибок для зарегистрированных пользователей будут абсолютно бесплатны.

С сегодняшнего дня мы начинаем принимать оплату за наши услуги в системе Приват24, одной из самых популярных систем для перевода денег в Украине и России.

Мы надеемся, что это повысит удобство работы с нами для наших клиентов.

Удачи!

Продаются следующие базы по строительной тематике:

1. База статей
   Количество статей: 4,779
   Общий размер базы: ~50 МБ (cp1251)
   Количество картинок к статьям: 13 376 (258 Мб)
   Поля в базе: id, категория, статья, изображения к статье.
   Количество источников: 4.
   Описание базы: качественная база статей на строительную тематику, проверенна на дубли. В базе оставлены ссылки на источники информации.
   Стоимость базы: 90 $ (WMZ)
   Пример одной записи из базы можно посмотреть тут
2. База строительных подсказок из серии «Как сделать…»
   Количество записей: 64.
   Общий размер базы: >1Мб (cp1251)
   Количество картинок: 105 (~2 Мб)
   Поля в базе: id, категория, тест, изображения к подсказке.
   Количество источников: 1.
   Описание базы: небольшая, но очень интересная база.
   Стоимость базы: 10 $ (WMZ)
   Пример одной записи из базы можно посмотреть тут
3. База строительных советов
   Количество записей: 401.
   Общий размер базы: >1Мб (cp1251)
   Количество картинок: картинок к данной базе нет.
   Поля в базе: id, категория, тест.
   Количество источников: 1.
   Описание базы: тоже очень интересная база, много полезных строительных советов.
   Стоимость базы: 15 $ (WMZ)
   Пример одной записи из базы можно посмотреть тут

В базе оставлены все теги и все ссылки на ПЕРВОНАЧАЛЬНЫЕ источники информации.

Дополнительные услуги:

1. Замена и удаление тегов в базах = 10 $ (WMZ)
   Оплата: разово за все купленные базы.
   Описание: вы можете заказать удаление любых тегов из базы, можете заказать замену одних тегов на другие, удаление ссылок … Одним словом – любые махинации с версткой.
2. Хранение картинок = 20 $ (WMZ) / год
   Оплата: разово за год за все базы.
   Описание: я могу разместить картинки к статьям на одном из своих серверов и при экспорте базы просто поменять пути к картинкам. Получится, что вам не надо будет задействовать лишнее место, и в тоже время вы сохраните все картинки в статьях.

В срочном порядке ищутся владельцы 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;    # завершили поток
}

У данного кода есть несколько преимуществ:

• многопоточность
• простота

и ряд недостатков:

• использование очень медленной LWP (и как ее подвида LWP::Simple)
• невозможность работы через прокси (добавить это легко, но мне было лень )
• никакого контроля за адресами и их валидностью - тупо, что получили, то Яндексу и кормим (это добавить еще легче, но мне было еще больше в лень)
• использование “дурного” метода обработки завершения потока.
  Я хотел использовать, что-то другое, но для него или не подходил мой Перл или работало оно явно не очень хорошо (как в случае с Threads::Queue).

Также скрипт не показал себя сильно производительным. На моем компе проверку 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, что поможет вам легко сопровождать и модернизировать код под ваши нужды. Если с умом подойти к граббингу и поставить нормальные интервалы, то можно без проблем собрать все картинки из выдачи. Также плюсом является то, что разработка не использует базы данных, так как последнее время именно они становятся узким местом на серверах. Если будут вопросы - вы всегда можете обратиться ко мне по адресам, указанным в контактах.

Удачи!