ParserPro

Поздравляю всех своих клиентов, подписчиков, партнеров и друзей с Новым Годом. Я уверен, что в этом году вы добились многого, но я верю, что Новый Год откроет перед вами бесчисленные горизонты возможностей и вы достигнете всех поставленных целей и осуществите свои самые заветные мечты.

Отдельно я хотел бы поздравить своих клиентов, которые доверили свои проекты моим рукам и оставили столь приятные отзывы о моей работе на Weblancer.net и Webmoney.ru. Спасибо вам огромное! Обещаю, что Новый Год мы с вами встретим с новой парсинг-платформой, которая позволит собирать и обрабатывать миллионы записей в сутки.

Поздравляю всех! УДАЧИ!

P.S. До 6ого января я буду в отпуске, поэтому прошу всех моих великолепных заказчиков немного потерпеть. Когда я вернусь с новыми силами я удивлю вас своей производительностью!

Как-то странно упала посещаемость моего сайта. Притом упала в разы. Видно Гугл и Яндекс наказывают меня за то, что я с них ссылки собирал :)))

Очень часто в процессе парсинга информации наши скрипты циклически проходят набор каких-либо урлов.

Если парсинг идет с одного источника с изменением, например, некоторых GET или POST параметров, то в любую единицу времени вы можете точно определить месторасположение своего скрипта. Но бывают случаи когда массив урлов собирается, например, с поисковика. И все было бы хорошо, если бы человек не придумал такую штуку как редирект и если бы ваш заказчик не требовал заносить УРЛ конечной страницы в базу данных.

А можете ли вы однозначно утверждать, что урл, который вы достали из выдачи Гугла однозначно равен урлу, на который зашел ваш скрипт и на котором он производил поиск информации? Если вы говорите “ДА”, то вы сильно ошибаетесь. Можете попробовать поэкспериментировать с такими запросами к Google как “Viagra” - половина сайтов будут либо дорвеями, либо прочими видами редиректеров.

И, поверьте, это всего лишь одна из ситуаций, когда в процессе парсинга/граббинга надо точно определять урл страницы, на которой находится ваш скрипт.

В качестве других типичных примеров можно привести сборы урлов из каталогов компаниий или каталогов галерей картинок. Как часто вы видите подобные урлы: http://www.site.com/redirect.php?id=700? Понятное дело, что подобное записывать в поле URL в своей базе просто стыдно :), потому что через пару часов вы уже не сможете гарантировать, что вышеуказанная ссылка будет ссылаться на тот сайт, на котором вы произвели поиск информации.

Я столкнулся с подобной проблемой при работе над одним проектом по сбору картинок с галерей изображений. Редиректеры вытворяли что-то нереальное: одна и таже ссылка на редиректере вела на разные сайты. И даже не надо было ждать пару часов - это происходило ежесекундно!

И это бы ничего, ведь даже file() умеет следовать редиректам. Но ведь заказчик потребовал в базе в отдельное поле писать конечный URL…

Решить данную проблему можно достаточно просто и вариантов ее решение есть несколько.

Самым разумным и быстрым из них будет использование функции curl_getinfo. И вообще я бы советовал всем программистам, которые используют библиотеку curl присмотреться к этой функции, ведь бывают ситуации, когда она может быть очень полезной.

Вот типичный пример использования данной функции в одном из моих классов:

function GetLastURL() {
	return curl_getinfo($this->curl_handler, CURLINFO_EFFECTIVE_URL);
}

В результате использования данной незатейливой функции вы получите последний урл, куда был перенаправлен ваш скрипт.

А что же делать, если вы не пользуетесь функционалом curl’a, а используете, например, file_get_contents()? Тогда прийдется немного поиграться в функцией stream_get_meta_data(). Вот типичное решение, которое я использовал в одном из своих проектов, где по ТЗ нельзя было использовать CURL:

$content = file_get_contents($url);
$fp = fopen($url,'r');
$meta_data = stream_get_meta_data($fp);
foreach($meta_data['wrapper_data'] as $response) {
	if (substr(strtolower($response), 0, 10) == 'location: ') {
		$last_url = substr($response, 10);
	}
}
fclose($fp);

Из данного кода я убрал все проверки и прочие функции, которые не имеют непосредственного отношения к обсуждаемой теме.

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

Пользуйтесь ими на здоровье в своих парсерах, грабберах и анализаторах и не никогда не теряйтесь!

Наконец-то удалось немного разгрести гору заказов и написать.

На прошлой неделе очень интересно получилось с моим тестом-сравнением скорости работы preg_replace() и str_replace(). Я провел измерения, результаты были вполне предсказуемые, но YS.PRO подкинул новый опыт, по результатам которого скорость str_replace() превысила preg_replace() в 24 раза! Конечно, это больше чем я ожидал, хотя также вполне прогнозируемо.

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

Поэтому пока никаких больше тестов. Надо завершить все проекты, подготовиться к Новому Году и уехать куда-то отдыхать!

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

На этом все. Удаляюсь. В следующих постах обещаю рассказать об интересных функциях curl и умном взвешивании результатов при сборе картинок.

Удачи!

Недавно к моему посту “Парсинг выдачи Google. Практика.” [YS.PRO] оставил коммент следующего содержания:

$Result=preg_replace(”/[\n\r\t]/”, ”, $Result);

Ох не нравится мне это, зачем комп мучать?
$result = str_replace(array(”\n”, “\r”, “\t”), ”, $result);

Конечно же сомневаться в том, что на данной операции str_replace() быстрее мне не приходится, но мне все-таки захотелось протестировать разницу в скорости при использовании этих двух функций.

Начальные условия:

• PHP 5
• Apache 2
• Параллельно запущено 4 громадных скрипта, которые уже проработали 3е суток, так что определенную погрешность из-за них можно ожидать

Тестирование производилось при помощи следующего кода.
Код №1

<?php 
require_once 'timer.class.php';
 
$text="Почему я делаю это?\r\nНе знаю, но это весело!\r\nВедь надо же стать легендой )";
echo $text;
 
$timer=new Timer();
$timer->start();
$Result=preg_replace("/[nrt]/",'', $text);
$point=$timer->stop();
echo $point;
 
if($fh=fopen('preg.txt','a')) {
	fwrite($fh,$point."\r\n");
	fclose($fh);
} else {
	echo 'Вечная ошибка с файловой системой!';
}
 
?>

Код №2

<?php 
require_once 'timer.class.php';
 
$text="Почему я делаю это?\r\nНе знаю, но это весело!\r\nВедь надо же стать легендой )";
echo $text;
 
$timer=new Timer();
$timer->start();
$result = str_replace(array("n", "r", "t"), '', $text);
$point=$timer->stop();
echo $point;
 
if($fh=fopen('str.txt','a')) {
	fwrite($fh,$point."\r\n");
	fclose($fh);
} else {
	echo 'Вечная ошибка с файловой системой!';
}
 
?>

Класс Timer имеет следующий вид:

<?php 
 
 class Timer
 {
 	var $timers		= array();
 	var $precision	= '';
 
 	function Timer($prec=6)
 	{
 		$this->precision=$prec;
 	}
 
 	function get_precision()
 	{
 		return $this->precision;
 	}
 
 	function set_precision($new_precision)
 	{
 		$this->precision=$new_precision;
 	}
 
 	function _getmicrotime() 
 	{
 		list($msec,$sec)=explode(" ",microtime());
 		return ($sec.substr($msec,1));
 	}
 
 	function start($timer='def')
 	{
 		$this->timers[$timer]=$this->_getmicrotime();
 		return true;
 	}
 
 	function stop($timer='def')
 	{
 		if(!array_key_exists($timer,$this->timers)) return false;
 		return round($this->_getmicrotime()-$this->timers[$timer],$this->precision);
 	}
 } 
?>

В результате тестирования были получены следующие результаты для preg_replace():
6.6E-5
0.212309
0.212233
-1.0E-6
-1.0E-6
-1.0E-6
0.000571
0.000126
0.000132
0.000443
И как результат среднее время: 0.0425877 секунд.

В свою очередь для str_replace() были получены такие результаты:
4.0E-5
4.2E-5
-1.0E-6
-2.0E-6
-1.0E-6
0.000291
0.212443
0.000484
0.000212
-1.0E-6
И как результат среднее время: 0.0213507 секунд.

Среднее время измерялось при помощи следующего скрипта:

 
$nums1=@file('str.txt');
$nums2=@file('preg.txt');
$sum1=0;
$sum2=0;
foreach ($nums1 as $num) {
	$sum1+=$num;
}
foreach ($nums2 as $num) {
	$sum2+=$num;
}
 
echo 'str:',round($sum1/10,12)."\r\n";
echo 'preg:',round($sum2/10,12)."\r\n";
?>

Выводы:
1. Для операции операции по скипу вайтспейсес лучше использовать str_replace, так как он в 2 раза быстрее аналогичного синтаксиса с preg_replace.
2. Так как операция по скипу вайтспейсов чаще всего проводиться 1 раз на цикл (или лучше сказать, один раз на этап обработки конечной страницы), то временем задержки в 0,02 секунды можно пренебречь как незначительным.

ЗЫ. Данные тестирования я считаю важными, так как они помогают максимально оптимизировать используемые механизмы для достижения наивысшим результатов. Поэтому в дальнейшем я постараюсь их проводить как можно чаще!