Переплюнуть Google

1. Сессия не треснет, но это моветон.

2. А какая связь массива и сортировки по дате -- в массиве ведь RSSки.

3. По скорости -- запускается скрипт локально или на сервере?

P.S. кешируйте данные.

P.S.P.S. Намного быстрей "в ручную" нежели simplexml или domxml не будет -- т.к. эти расширения написаны на C...

Ну и многопоточность... это есть основной +(если не плюсище) в сторону JAVA|PERL|C.

ossadchy добавил 11.11.2008 в 19:15

у веб-сервера процессор другой или канал уже? :)

Качать фиды нужно параллельно. А примерный парсинг вот.

// парсим rss

$needtags=array('title','link','description','pubdate');

$img='/<item>(.*?)<\/item>/ims';

preg_match_all($img,$str,$temp);

$itm=$temp[1];

$items=array();

foreach($itm as $k=>$v) {

$items[$k]=array();

$img='/<([^>]+)>(?:\<!\[CDATA\[)?(.*?)(?:]]>)?<\/\1>/ims';

preg_match_all($img,$v,$regs,PREG_SET_ORDER);

foreach($regs as $v2) {

$v2[1]=strtolower($v2[1]);

if ('category'!=$v2[1]) {

$items[$k][$v2[1]]=$v2[2];

} else {

if (!isset($items[$k][$v2[1]])) $items[$k][$v2[1]]=array();

$items[$k][$v2[1]][]=$v2[2];

}

}

for ($q=0;$q<count($needtags);$q++)

if(!array_key_exists($needtags[$q],$items[$k])) {

unset($items[$k]);

break;

}

if (!isset($items[$k]['category'])) $items[$k]['category']=array();

}

В массиве simple_xml - объекты SimpleXML (это не полный дамп сейчас там выдается, - я "шелуху" поотрубал), есть другой массив (он в коде на fasion25 сейчас закомменчен) - там результаты парсинга всех фидов (данные о канале и итемах + дата, по которой происходит сортировка штатной функцией)

На сервере - локально куда дольше получается.

Данные будут кешироваться - без этого, конечно, никак. Сейчас не цель сделать последующую обработку быстрее, - сейчас цель сделать первичную в разы быстрей (Вы будете ждать пол минуты на загрузку, когда на Гугл.Ридере всё грузится 4 сек., даже если потом будет всё моментально загружаться?), это просто приоритетная задача, которую нужно решать прямо сейчас.

Сейчас человек один хороший подсказал использовать многопоточность cURL (в конце-концов скорее-всего она именно для подобных случаев и была реализована) - я буду пробовать разные варианты - какой вариант окажется наиболее "шустрым", - тот и будет в финальной реализации, хотя изначально я не буду ломать мозг и сделаю наиболее эффективным и простым способом, - потом всё остальное - я пока что сконцентрирован на цели получить наиболее хороший результат и остановиться на нем или же отказаться от идеи создания этого сервиса. При том я пока что проверил только на 1, 4 и 9 фидах и уже результаты неудовлетворительные, приемлемым будет результат менее 6 секунд на загрузку примерно 20-30 фидов (не проводил социальных исследований, но думаю, что среднестатистический пользователь интернета врядли читает больше лент постоянно).

Если качать multi_curl-ом, то время загрузки 1 и 1000 фидов будут примерно одинаковы.

Прогнал мой вышеприведённый код по случайному фиду (20 постов) в цикле на 1000 интераций 8-9 секунд выходит (на сто интераций - 0.9 сек). Так что

более чем достижим. И упираться всё будет во время скачки самого медленного фида, а не в скорость парсинга (про неё см чуть выше). А уж время работы php+apache+mysql в данном случае настолько мизерно, что рассуждения php vs perl vs си и файлы vs mysql выглядят достаточно глупо.

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

(10М\1000 = 10485. )

а для Вас новинка, что из-под него идет выполнеие иначе?

Вы слушаете только то, что хотите услышать. Я утверждал что есть задачи, где монстр типа SQL сервера нужен и оправдан. Решение без него - затруднительны. В приведенном примере, в большинстве веб-приложений и CMS использвать базы не удобно и ведет к очень серьезным "тормозам".

Решения, с использованием mySQL, входят в любой учебник по пхп. При этом, они рассмотрены как примеры, а не как готовые интересные решения. Вот их и юзают все кому не лень.

Любое универсальное/стандатроное решение (тот же SQL) все проигрывает перед ускоспециализированным. Еще раз повторюсь, и для него есть задачи, но обсуждаемые здесь к ним не относятся