Форум Сайтостроение Веб-строительство

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

12 3
[Удален]
1673

Написал я класс для чтения RSS.

Пример использования:


$feeds = array("http://www.interblog.net.ru/feed/",
				"http://cyber.law.harvard.edu/rss/examples/sampleRss092.xml",
				"http://www.seoskazki.ru/cache/rss_news.xml",
				"http://sanuin.blogspot.com/feeds/posts/default",
				"http://www.cv-go.net/cvgo/ArticlesRSS.ashx",
				"http://www.vacansia.ru/export/vacrss.php",
				"http://staff-ua.com/worker/rubric.php?id=7&vtd=rss2",
				"http://www.zprabota.org.ua/rss.xml",
				"http://jobit.ru/modules/rss_vac.php");

$rss_feeds = new rss ($feeds);
$rss_feeds->debug = true;
$rss_feeds->parse();
$rss_feeds->show_dump();

Этот пример можно посмотреть сейчас на fasion25.ru. Внизу - количество секунд на загрузку документа.

Сама по себе обработка занимает порядка 8 секунд (чуть меньше секунды на один rss-фид), сейчас там еще идет вывод дебаговой информации (по сути PHP-форматированный код).

Загрузил все эти RSS-фиды в гугл-ридер и очень удивился скорости загрузки...

Почему сделано массивом? Очевидно - для сортировки по дате (пользователю интересней самые последние новости).

Предзагрузка на google reader занимает примерно 4 сек (у меня к сожалению нету возможности встроить в google reader счетчик для предоставления более точных данных :) ). Возможно, что на гугл ридере сделано следующим образом - сначала данные парсятся, далее, после загрузки страницы, данные вынимаются при помощи AJAX.

Мой скрипт парсит данные примерно 8 секунд и примерно 10-15 секунд (у меня, например) тратится на загрузку самой страницы (ЭТО СЛИШКОМ МНОГО!).

Если выключить функции cURL для определения есть ли редирект (например на некоторых блогах я нашел редирект), то сэкономится примерно 1-2 секунды.

Парсинг происходит при помощи SimpleXML, но функционал еще не дописан немного, т.е. по идее, время на парсинг должно будет увеличиться еще втишь...

Хотя, если использовать PEAR::RSS, будет гораздо хуже (тупой класс, если честно)...

Может быть парсить "вручную"? Т.е. при помощи cURL получать весь контент и парсить как строку, не прибегая к использованию классов типа SimpleXML, DOMDocument, XML Parser (PEAR::RSS вообще отдельная статья - полил бы бензином и сжег эту гадость)... Какие идеи? )

Вопрос второй: если все результаты хранить в сессии, - сессия не треснет? (см дамп) )) Хранить всё это дело в БД не выгодно... А так - запарсил данные, запихнул в сессию, выдал юзеру страницу, передал количество резульатов, которое должно быть на странице... далее JS: пока (все записи не показаны) достаем при помощи AJAX из сессии очередную запись и показываем юзеру - пока он первые новости читает - подгрузятся все остальные...

Есть еще один вариант - показывать юзеру страницу, показывать его подписки, а тем временем, пока юзер думает, что ему делать, парсить данные втихушку :) Тогда нам пригодится таймер (setInterval), чтобы постоянно спрашивать серверный скрипт "уже готово?", когда он ответит "ага, забирайте!" - показывать данные...

Идеи/предложения/критика?...

Zhilinsky
На сайте с 05.08.2007
Offline
86
Zhilinsky
#1

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

А парсил бы скриптом по крону.

Жилинский (http://жилинский.рф/).
newseditor
На сайте с 13.11.2006
Offline
123
newseditor
#2

40 seconds for parse

3 seconds for load

43 total time for load

T.R.O.N
На сайте с 18.05.2004
Offline
314
T.R.O.N
#3
So1:
Может быть парсить "вручную"?

нужно. Это будет быстрее. Но Еще быстрее все будет происходить, если отказаться от PHP. Используйте любой настоящий CGI - Perl/TCL/Phyton.

При этом, еще использовать "ручную" загрузку самих лент. Это позволит вести паралельную обработку. Разделенные процессы очень сильно ускоряют программу.

So1:
Хранить всё это дело в БД не выгодно.

Очень выгодно. Просто не нужно использовать SQL. Текстовый файл - это тоже БД.

От воздержания пока никто не умер. Хотя никто и не родился! Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript (Richard Cornford)
[Удален]
#4
T.R.O.N:
нужно. Это будет быстрее. Но Еще быстрее все будет происходить, если отказаться от PHP. Используйте любой настоящий CGI - Perl/TCL/Phyton.

Мда... давненько я не писал на Perl'е - видимо прийдется вспоминать...

T.R.O.N:
При этом, еще использовать "ручную" загрузку самих лент. Это позволит вести паралельную обработку. Разделенные процессы очень сильно ускоряют программу.

Что за "ручная загрузка самих лент"?

И все же вопрос остался - есть ли ограничения на длину сессии? До сих пор хранил там небольшие строковые данные только...

Zhilinsky:
Я бы подцепил SimplePie и сложил бы данные из лент в кеш - или в базу, или в файлы, а при запросе пользователя отдавал бы уже оттуда - на порядок быстрее.
А парсил бы скриптом по крону.

До SimplePie руки не доходят разобраться что-то - скачал уже давно, посмотрел и забросил... насколько я помню там RSS парсится как раз "вручную", т.е. как строковое данное.

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

newseditor:
40 seconds for parse
3 seconds for load
43 total time for load

Спасибо за тест. Что то чересчур долго ))) У меня результаты в разы лучше :) Хотя один фиг результаты плохие...

Вообще... про перл я как то позабыл - надо было с самого начала на перле делать... :(( Ну или по крайней мере этот скрипт...

T.R.O.N:
Текстовый файл - это тоже БД.

Текстовый файл работает быстрей SQL? Ну я конечно сделаю тесты (на 5-10, 100-1000, 10.000-50.000 записей), но что-то мне кажется, что БД будет предпочтительней... Раньше просто как то даже не возникало желания протестить БД vs Файл...

И еще вопрос на засыпку, - а что собственно лучше? C++, Perl, Python, TCL? наверное C++, но на C++ парсить заколебусь, очевидно, - наверное будет как альтернатива на будущее...

[Удален]
#5

Время доступа к текстовому файлу в разы меньше чем к БД, поэтому для хранения _уже упорядоченных_ данных (когда не нужно делать сложные отсевы или они делаются простым смещением бегунка чтения), это идеальный вариант.

Мне кажется что на C++ парсить вы не заколебетесь, ибо там есть почти все те же строковые функции что и в PHP, регулярки тоже туда подключаются. Но я бы предложил таки перл. С распараллеливанием процессов.

T.R.O.N
На сайте с 18.05.2004
Offline
314
T.R.O.N
#6
So1:
Что за "ручная загрузка самих лент"?

использовать модуль Net::Socket::NonBlock или подобный, который позволит одновременно вести загрузкув 16,32,64 потока

So1:
Текстовый файл работает быстрей SQL?

Да, значительно. Только нужно грамотно с ним работать. При объеме до 30-40Мб (Perl 5.10) он значительно быстрее MySQL, при этом мение ресурсозатратен.

Стараюсь нигде SQL не юзать. Медленно, грамоздко и очень много ограничений.

Не забывайте, что Perl, в самом начале, был создан тольок для парсинга/структурирования текста

So1:
И все же вопрос остался - есть ли ограничения на длину сессии?

Зачем в этой ситуации сесии вобще.

1. получили рсс, пропарсили и оставили лежать в виде результирующих файлов-файла.

2. Повторно читаем рсс ленту тольок по истечении времени ее актуальности или тупо каждый 10-20-30-60 минут. До это времени отдаем из сохранения.

So1:
C++, Perl, Python, TCL?

то, что быстрее работает на серваке и иметт необходимые модули

T.R.O.N добавил 11.11.2008 в 13:12

neolord:
Время доступа к текстовому файлу в разы больше чем к БД, поэтому для хранения _уже упорядоченных_ данных (когда не нужно делать сложные отсевы или они делаются простым смещением бегунка чтения), это идеальный вариант.

Вы можете это доказать? Есть хоть какие-то тексты не из учебников?????

[Удален]
#7

perl по-моему изначально был создан для генерации каких-то там отчетов... каким-то там сотрудником какой-то там фирмы, но потом вроде как разросся - спорить не буду, да и историю перла щас в лом читать :) Но работать с регулярными выражениями на нем помню мне жутко нравилось... Более полутора лет не писал на нем - сейчас вот залез на сайтик - вспоминаю...

:)

T.R.O.N:
использовать модуль Net::Socket::NonBlock или подобный, который позволит одновременно вести загрузкув 16,32,64 потока

Это перловский, насколько я понимаю?...

T.R.O.N, посоветуете интернет-источники по Perl?... Можно на английском.

eTarget 2011:Панельная дискуссия «Стратегия eTarget 2011: Круглый стол Могут ли «плохие» входящие
Progr@mmer\.
На сайте с 14.10.2007
Offline
44
Progr@mmer\.
#8

Всё дело в том, что у гугла когда добавляешь рсску она уже в 90 случаев из 100 распарсена и лежит в бд. Не будет ведь гугл для каждого пользователя хранить одни и те же данные отдельно. Поэтому там всё так быстро загружается - ведь нет никакого парсинга и скачивания рсс.

Вашей девушке не хватает романтики? Черпните её на сайте «Я Люблю Романтику» (http://iloveromantics.ru/). Романтический форум (http://forum.iloveromantics.ru/) для отдыха от нудной работы.
[Удален]
#9

и еще каким лучше редактором пользоваться (лучше именно для perl написанный), - я качаю этот - надеюсь хороший.

So1 добавил 11.11.2008 в 13:46

Progr@mmer\.:
Всё дело в том, что у гугла когда добавляешь рсску она уже в 90 случаев из 100 распарсена и лежит в бд.

Не правда... Я конечно признаю, что гугл использует просто какие то космические технологии, раз выдерживает такие нереальные нагрузки и выдает результаты (я про поисковик) за доли секунды, но не до такой же степени... Я добавил туда ленты и самой вежей новости было тогда 1 минута - гугл.ридер ее показал - хотите сказать он такой нереальный объем фидов парсит ежесекундно? ну или раз в 20-30 секунд? Сотни тысяч фидов.... не - не верю! (с)

Пусть тогда АПы PR выдает раз в 3 часа... ))

T.R.O.N
На сайте с 18.05.2004
Offline
314
T.R.O.N
#10
So1:
T.R.O.N, посоветуете интернет-источники по Perl?

http://activestate.com/index.mhtml именно его и пользую, как софт.

http://webscript.ru/stories.php3?topic=5

So1:
Я конечно признаю, что гугл использует просто какие то космические технологии, раз выдерживает такие нереальные нагрузки и выдает результаты (я про поисковик) за доли секунды, но не до такой же степени

поверьте, в гугле, как и яше - все достатчно просто. Все алгоритмы, как правло, - линейные. А значит имеют максимальную скорость исполнения. Все что может быть расчитано зарание - расчитано, и сохранено в виде дампов памяти переменных (кажется это называется бадзами Баркли/Барклая). Это самый быстрый способ хранения данных, но требует большие объемы памяти. Пердварительные данные готовятся другими серверами.

So1, У вас сейчас скрипт делает все последовательно, поэтому время складывается. А можно попытаться разделить все процессы.

Возможно даже построение псевдо клиент-сервер.

Т.е. бинарник(ведь он всегда быстрее работает, да и запушен не под web-сервером, что еще увеличивает скорость), на том-же си или делфе запущен и постоянно анализирует запрос к себе(появление файла или пайпа или еще чегонить). Получает этот сигнал, выполняет запрос к ленте и складывает результат.

А у серверного скрипта задача очень простая - дал запрос бинарнику - получил ответ - объединил начало страницы результат и конец.

T.R.O.N добавил 11.11.2008 в 14:31

So1:
Пусть тогда АПы PR выдает раз в 3 часа... ))

а Вы понимаете, почему именно он этого не делает? Или Вы считаете что это связано только со скоростью обработки?

12 3

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий