realtime(?) aggregation

Статус
В этой теме нельзя размещать новые ответы.

капрал

Профессор
Регистрация
2 Окт 2008
Сообщения
337
Реакции
46
может кто сталкивался с проблемой, есть около 15 урлов фидов. в определенный момент необходимо одновременно и как можно быстрее собрать содержимое этих фидов. Причем кэширование использовать нельзя - это одно из главных условий. У меня в голове есть несколько решений:
1.последовательный curl по всем урл - самый длительный способ, так как перед следующим коннектом необходимо дождатся результатов предыдущего - очеывидно что не риалтайм вовсе.
2.milticurl на все урлы сразу - к сожалению время агрегации сокращаесться только на 60% (проверял) - тоже не риалтайм но приемлемо в некоторых исключительных случаях.
3.fork - к сожалению небыло времени проверить, но исходя из прошлого своего опыта смею предположить, что производительность на уровне multicurl или лучше, но возникает дополнительная потреблность централизированого временного места для сбора результатов отдельных fork'ов, с последующий соединением в общий фид (как это реализивать пока еще не придумал)

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

спасибо.
 
может кто сталкивался с проблемой, есть около 15 урлов фидов. в определенный момент необходимо одновременно и как можно быстрее собрать содержимое этих фидов. Причем кэширование использовать нельзя - это одно из главных условий. У меня в голове есть несколько решений:
1.последовательный curl по всем урл - самый длительный способ, так как перед следующим коннектом необходимо дождатся результатов предыдущего - очеывидно что не риалтайм вовсе.
2.milticurl на все урлы сразу - к сожалению время агрегации сокращаесться только на 60% (проверял) - тоже не риалтайм но приемлемо в некоторых исключительных случаях.
3.fork - к сожалению небыло времени проверить, но исходя из прошлого своего опыта смею предположить, что производительность на уровне multicurl или лучше, но возникает дополнительная потреблность централизированого временного места для сбора результатов отдельных fork'ов, с последующий соединением в общий фид (как это реализивать пока еще не придумал)
помогите советом, что еще я пропустил, может у когото есть какой-то опыт решения подобной проблемой. может быть у вас родились какие-то идеи по прочтению данного топа.
спасибо.
Если время ой как критично - то можно использовать неблокирующие сокеты, они точно будут быстрее чем курл, хотя не так чтобы небо и земля. Но надо понимать -
1 если сам рсс фид имеет некий пинг то ускорить загрузку ничего не сможет. Есть точная уверенность что время загрузки самого долгого фида намного меньше чем скорость скрипта с мультикурлом?
2 Если происходит некий разбор структуры фида, то и она может отнимать значительное время.

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

думаю лучшим будет именно в реалном времени подгружать через ajax каждый фид по отдельности и выполнять сортировку/парсинг на строне клиента средствами клиента
 
вот как раз общее время не должно быть большк чем время звгрузки сомого медлительного фида
время не должно быть большк в смысле времени затрачивается больше?
думаю лучшим будет именно в реалном времени подгружать через ajax каждый фид по отдельности и выполнять сортировку/парсинг на строне клиента средствами клиента
Хороший вариант, хотя всего тз я не знаю. Надеюсь, подгружать через ajax каждый фид предполагает всё таки подгруздку с собственного сервера, который через curl или сокеты будет тянуть данные. Т.к с помщью только ajax\javascript нельзя обратится к сторонемму сайту и получить данные для обработки (если конечно эти сайты не настроены соответственно).
 
время не должно быть большк в смысле времени затрачивается больше?

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

Вобщем, остаются неблокирующие сокеты или ajax.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху