Pull to refresh

Comments 173

Столько информации, много очевидного, мало деталей интересных реализаций. Лучше было бы по частям описывать интересные загогулины и как вы их обошли, и на какие грабли наступили. Но доходчиво. А то галопом по Европам.

Ну и это… зарекламили статью как презентацию ридера. И где он?
Изначально так и начал писать, но получилось слишком растянуто.
Особо детально описал работу бекграунда и очередей, поскольку считаю это более интересным.

А вообще, так и хотелось — передать все в общих чертах, не углубляясь сильно в детали. Слишком много для одной статьи.

Я же сказал, что презентация будет потом, а эта статья несет чисто технический характер…
Эта статья несет мало технически интересного. Я использовал strreplace и Smarty, пришлось помучаться с юникодом
А Вы до пункта 9 дошли?
Прочитал, все, весь текст, облизывался на новый ридер и правда, где он?
На следующей неделе анонсируем его на хабре.
Ждем! Было бы круто, если бы в анонсе описали чем он круче 2 ридер-монстров этого времени — Гугл Ридер и Нетвайбс.
Мы очень хорошо изучили рынок, прежде чем делать что-либо (да и во время разработки). Есть еще bloglines, который тоже имеет не маленькую аудиторию с США.

Опишем.
UFO landed and left these words here
Так я на нем все делал!
Не надо! Уверен — Дениска сделает ридер гораздо-более-лучше.
Прямо ждать терпения не хватает =)
UFO landed and left these words here
Я бы добавил в список Feedly. Для меня это идеал ридера.
Спасибо, обязательно изучим. Выглядит интересно.
UFO landed and left these words here
Вы прочитали мои мысли и избавили меня от тяжкого бремени делать ридер самому.
Впрочем, я бы немного изменил систему подсчета TTL на следующий день, учитывая паттерн, сложившийся на завтрашний день недели и за прошлый месяц.
Еще одна очень нужная фишка — генерация RSS из всех фидов в данной папке, этакий миксер потоков.
И, пожалуй, как завершение, как вишенка на пирожном, нужна кнопка на любом сайте «добавить RSS-поток с этого сайта в читалку». Маленькая иконка, которая сэкономит время.
Спасибо.
Генерация фида из папки уже работает.

По поводу кнопки:
Мы будем делать удобный букмарклет. И постараемся, чтобы даже домохозяйка смогла им воспользоваться. Позже.
А про монетизацию использования приложения статья будет? Интересно было бы почитать.
Про монетизацию мы, скорее всего, писать не будем.
Могу сказать, что она будет несколько необычной и очень лояльной к пользователю.
Ну тогда вдвойне заинтригован :)
Если сервис бесплатный — то это реклама. Что необычного?)
Скажите, когда появилась контекстная реклама, она была необычной?
Скажите, вам не становится страшно когда вы думаете как поддерживать такой зоопарк технологий?
почему было не использовать эрланг? зоопарк действительно дикий, вы бы сэкономили массу времени и сил, при этом система у вас еще сырая, по вашим же словам…
да, оно идеально ложится как раз на связанное с очередями, воркерами, интерактивной отладкой, масштабированием и прочим
кстати, например, для монго есть библиотека
интегрируется с другими языками через безопасные «порты»
я писал кравлер, и после это писать такого рода сервера на чем-лтбо еще видится мне садомазохизмом )
Мое знакомство с эрлангом… в общем, мы с ним не подружились.
Слишком неведомое.
Дак приступайте, станете «неспать» спокойно
Чем конкретно erlang превосходит node?
(учтите, что у меня уже все на нем реализовано)
Название конфликтует с лозунгом «Без велосипедов».
Это не копикат. Обоснуем в релизе.
UFO landed and left these words here
Ну, по поводу заголовка и велосипедов очень четко подмечено.

Говоря «Rss ридер» я имею ввиду техническую характеристику, а вовсе не специфику проекта. Ведь это разные вещи, верно?
UFO landed and left these words here
UFO landed and left these words here
Аггрегатор и ридер совсем разные программы. Тут явно много времени было уделено интерфейсу. Но 2000 ч.часов это сильно да. 250 рабочих дней по 8 часов. Если не ошибаюсь Торвальдс ядро линукса быстрее написал
Я так понимаю, у Вас за спиной — десяток таких проектов…
Это вам у Линуса лучше спросить. Я всего лишь сравнил
Ядро линукса и веб приложение совсем разные программы.
А это мы его замаскировали под rss reader
Когда задача выбирается из очереди, на нее ставится Lock (для блокировок используется memcache)

вот он FAIL
Например ново-модный Redis, он поддерживает транзакци
Почитал, очень интересно и просто… и поздно :)
Спасибо, буду иметь ввиду.

Очереди переделаю на Redis.
Почему бы не заточенными решениями типа RabbitMQ (или ZeroMQ если гарантия доставки не важна)?
AMQP/RabbitMQ — по мне так хорошее решение для очередей.

Очень надёжное и быстрое, используем много где.

Кстати, есть github.com/ry/node-amqp
Уже переделал все на Redis:
lists, distributed Locks, pub/sub

Очень удобно все получилось.
Только это не привычные по rdbms транзакции, а скорее балковое исполнение команд.
В свое время 5 лет назад на заре расцвета AJAX писал RSS-ридер для нашего портала — rss.i.ua
Поэтому проблемы с тем, что приходит в RSS-потоке и в каком виде — нуууу очень понимаю :)))) Костылей там приходится очень много повставлять.
мне больше всего в вашем сообщении понравился домен i.ua :-)
Спасибо. Видно, понимаете, о чем шла речь :)
UFO landed and left these words here
Прочитал домен со второго раза. Первый раз прочитал как «russia»:-)
меня напрягает такое обилие слэнга (зачастую сугубо индивидуального, видимо) — это добавляет неоправданной сложности. часто это является следствием того, что желание похвастаться довлеет над желанием поделиться знанием.

а так ниче. раскрыты некоторые грабли которые нас ждут при использовании новомодных штучек.)
UFO landed and left these words here
Не нужно считать проблемой то, что собьется какой-нибудь счетчик.

Поддерживаемые MongoDB атомарные функции решают эту проблему. Пример: {$inc:{counter:1}}

А вообще довольно объёмная работа. Мне кажется, что вам помог бы нескольконедельный отдых после такой дикой нагрузки, ну там Карелия с байдарками, или ещё какие-нибудь прелести активного отдыха далеко от дома.

Удачи!
{$inc:{counter:1}}
так и происходит

Спасибо!
Мобильную версию (Android, iPhone, iPad) не делали?
Будем делать, но не в ближайшем времени.
С этого могли начать. Из всего разнообразия ридеров под android не один мне не подошел. Пользуюсь gr mobile.
А переписать mongomapper на js это велосипед? я вот тут начал ввиде плагина к express писать, только там проблема возникла пока с jspec либой. Проект еще сырой документации нету, но вот написать mongomapperjs очень хочется.
Посмотрите mongoose, он имеет вполне достаточный минимум для работы с моделью. Мне пока хватает.
О спасибо. Как раз то, что нужно. Когда искал не нашел такого.
Если делать только ридер — да, я с Вами согласен.

Но мы делаем не ридер.
>Без велосипедов
это вычеркниет. ведь ваш рсс-ридер — сам по себе велосипед.
В данном случае он более близок Лунапарку
Кажется, я уже отвечал на подобный комментарий…
Такой объем лучше по частям. А на ридер я бы с удовольствием взглянул:)
Так это, как бы, часть :)
Очень вкусно описал процесс, спасибо.
Где бы теперь подписаться на анонс ридера, чтоб не пропустить ненароком?
Анонс появится либо в разделе «Стартапы».
Называется Eventr.

Спасибо.
Он.

Но то, что там написано, уже слегка устарело… :)
Вот это да!

Я и сам недавно заморачивался многим из вышеперечисленного (и сейчас заморачиваюсь) — node.js, MongoDB, сервер очередей написал тоже, правда более примитивный. На этом действительно можно делать очень интересные вещи ))
Вот сейчас к этому всему добавится Redis и стает еще интересней :)
Да, Redis и MongoDB, на мой взгляд, самые подходящие кандидаты на роль «стандартного» хранилища данных в пару к Node.js. Riak тоже выглядит интересно, но с запросами там сложновато )
Riak я поздно заметил, решил уже не ковыряться… но говорят о нем действительно позитивно.
А я как раз ковыряюсь. Ему бы интерфейс для простых запросов как у Монго — цены б ему не было )
Вы очень крутой! А еще перфекционист.
Жаль, что подобный подход к работе конфликтует с личной жизнью и всякими увлечениями.
Расскажите, что вас мотивирует?
По поводу перфекционизма, меня очень сильно впечатлил вот этот доклад:
vimeo.com/10922497

Мотивирует, наверное, то же, что мотивировало дядечку Эйнштейна, и еще другую тысячу психов по всей планете.
Заметил перфекциониста — и это офигенно похвально! Таких весьма совсем не очень. Сам сейчас пишу биллинг на Nodejs и mongodb, плюс API на стороне ZF. И мне нравится серверный JS!

Народ, включайтесь в группу Nodejs и остальные похожие по теме группы на гугле — русских там 1.5 человека пока.
Подключился!!! Сам только сегодня начал ковырять и в восторге!!!
по поводу велосипедов
что конкретно может заставить пользователей уйти с Google Reader?
Смотря каких. Их там много.
В другой статье все расскажем.
Могу посоветовать добавить поддержку Digest-авторизации, этого так не хватает в GR для чтения подзамочных записей ЖЖ.
в жж подзамок можно читать через user:pass@livejournal…
На хабре где-то была тема про подзамки и gr.
Люди не хотят свои пароли светить сторонним сервисам. И это правильно.

Пришло время OAuth.
Чем обоснован отказан от реляционных баз данных в пользу монго? Ридер проектируется с расчетом на гигантские нагрузки или вы просто поддались модному тренду «noSQL»? :)
Повелся на модный тренд. Но если будут гигантские нагрузки — буду только рад :)

А Вы лучше скажите, зачем использовать реляционную бд, если ее «реляционность», в итоге, используется на 10%? (в нашем случае)

+ schema-less
+ легкие миграции
+ data-driven queries (очень нравится)
+ нативный шардинг, в случае чего
+… можно перечислять
Спасибо, прочел.

«Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.» — про меня
«Ниша NoSQL — высоконагруженные сайты, вырастающие из стартапов.» — надеюсь, про наш стартап

А Вы, в свою очередь, посмотрите вот этот доклад:
www.infoq.com/presentations/Facebook-Software-Stack

И оцените, как фейсбуку приходится использовать MySQL.
Чото вы мелко сравниваете — фейсбук…
Давайте сразу на примере гугла, выш стартап ведь, вы надеетесь, не меньше нагружен будет.
Вот когда ребята начинали делать фейсбук, думали так, как Вы. Либо вообще не думали.
Откуда вы знаете, что они думали?
Не иначе — вы думаете, что они так думали :)
Да, следовало бы вставить слово «наверное» :)
ето просто прекрасно! (с)

а для распределения нагрузки gearman были идеи использовать?
для redis вродь наиболее оптимальным решением сейчас есть libredis с поддержкой ketama, нескольких серверов и batch-запросов. или есть какие-нить другие идеи?
Спасибо, посмотрю.

Буду колупать Redis на днях. Скорее всего, прикручу его к node и на этом пока остановлюсь.
мы вот сделали такую систему на базе Gearmand и Zend_Reader — работает все отлично, уже в продакшине почти полгода. Единственная проблема — всякая фигня непридсказуемая в лентах. Например, многие ленты по особенному трактуют поле даты новости и она часто неверно понимается парсером.
Zend_Reader пришлось хорошенько дописать :)
вот читаю такие посты и понимаю что я очень много еще не знаю мягко говоря.
Ждем читалку
Очень хотелось бы взглянуть на ваш карказ над ZF.
Простите, «каркас» конечно же. конец недели…
Даже не знаю, как Вам его показать…
Что именно интересует?
о, можете показать какой-то gateway и mapper для mongodb? также на entity для етого.
на использование acl внутри сервиса тоже интересно взгянуть б (интересно как, вот).
Описание контроллера и менеджеров — один-в-один supervision tree из Erlang'a (gen_supervisor, gen_server) Это не упрек в велосипедности :) Просто показатель того, что рано или поздно разработчики приходят к похожим архитектурным решениям.

По поводу ридера главный вопрос — HTTP Digest Authentication, которая есть, например, в livejournal'е Ни один онлайн сервис, насколько знаю, не поддерживает ее, а хотелось бы :)
Это не сложно сделать. Находится в списке фич, которые собираемся запустить в первые месяцы.
Спасибо, очень интересно было читать!

PubSub прикручивайте — он (с точки зрения ридера) простой как сапог, зато позволяет для фидов, что его поддерживают, практически мгновенно доставлять сообщения, в обход общей очереди feed pull-а.
собирался писать ридер для себя и очень рад, что, наверное, не придётся :)

Будет ли импорт/экспорт фидов в OPML? будет ли HTTP Digest Authentication? Было бы очень неплохо
Про OPML написано в статье.
Так же, планируем сделать Google Reader Connect, который, скорее всего, позволит двумя кликами сделать импорт/экспорт — без всякого opml. Но пока руки не дошли до его API.

По поводу HTTP Digest Authentication, читайте пару комментов выше.
Почтовый клиент все равно удобнее.
Не люблю. В рсс ридере было удобнее.
Единственный удобный для меня ридер — это версия Google Reader для айфона, по адресу google.com/reader/i/, она и легкая, и удобная, и не перегружена ничем лишним.
для айфона?) Уверены что гугл делал это специально для айфона?)
насколько кртитичная информация хранится в очереди memcacheq? я имею ввиду — что будет, если вдруг случайно очередь потеряется?
В основном — действия пользователей в виде подписок на потоки и импорт за последние 1-5 минут максимум.
Плюс, могут устареть слегка сами потоки.

Сейчас как раз делаю так, чтобы она не терялась (избавляюсь от memcached).
«Все, что я имел с самого начала, это небольшой каркас, делающий работу с zf слегка удобней. » А каркас ваш или это какое-то общедоступное решение?
Этот каркас достался по наследству с другого проекта, который побывал на продакшн. Делался он «коллективным разумом», пережил довольно много usecase-ов.

Кстати, работа с zf мне вообще не напрягает мозг. Как-то так все с ним очень просто получается.
а зачем PHP здесь?
что мешает все-все-все на node.js сделать?
присоединяюсь к вопросу, нужен эксапорт в fb2
года два назад делал свой ридер. Все мечты разбились когда увидел fav.or.it(который загнулся по неизвестным причинам) и обомлел. А вы имея перед глазами gr и netvibes работали почти год, поэтому мой вам поклон.
На самом деле, живем этой идеей уже полтора года.

Спасибо.
Спасибо за статью и всем за коменты!!! Теперь точно не высплюсь (( Пошел ковырять node.
Каркас для ZF псмотреть бы… (скромно)
«Так же, существует WorkerPhp.js, который запускает php-cli как child-process и общается с ним на json»
объясните пожалуйста, а как вы держите эти PHP не закрытыми? черех php-fpm?
и это наверное у вас не php-tcp сервер, я правильно понимаю?
Да, где-то так:

while ($request = fgets($this->_stdin)) {
    $this->handleData($request);
}
Т.е. все-таки воркеры в режиме tcp-серверов, открываете их на портах и общаетесь с ними?

У меня проблема выбора или php-fpm или в качестве tcp-серверов воркеры пускать, что вы бы посоветовали?
Это не tcp, это простой std I/O. Работает замечательно, поскольку основной упор времени именно на выполнение задач, передача данных в моем случае — спички.
Помоему, tcp необходим только в том случае, когда нужно общение между разными серверами.
Пример:

$this->_stdin = fopen('php://stdin', 'r+');
$this->_stdout = fopen('php://stdout', 'w+');
Спасибо большое, попробовал.

К сожалению один воркер в памяти сьедает до 20 мегабайт ОЗУ. 100 воркеров сьедают 2 гигабайта(что не предел из-за динамического кол-ва воркеров и динамически-меняющегося необходимого кол-ва ОЗУ отдельно взятому воркеру).

Справедливости ради надо сказать, воркеры в формате TCP едят не меньше, как и воркеры NODEJS в режиме child_process.spawn)

Если не секрет, какое кол-во ОЗУ сьедает ваш PHP-воркер в среднем?
> К сожалению один воркер в памяти сьедает до 20 мегабайт ОЗУ. 100 воркеров сьедают 2 гигабайта
Зачем Вам 100 воркеров? У меня максимум 30 воркетов на сервер, и то, это сделано ради повышения эффективности работы с блокирующим I/O в php, а вовсе не ради ресурсов. Мои воркеры гребут rss, 90% времени его работы занимает трансфер данных из внешних источников. Было бы весьма разумно реализовать это на nodejs, но на этом завязано слишком много бизнес-логики в среде php.
Система работает эластично — если нагрузка небольшая, запущено в среднем 5 воркеров.

> Справедливости ради надо сказать, воркеры в формате TCP едят не меньше
Чем воркеры «в формате TCP» принципиально отличаются от воркеров «в формате I/O»? И что побужтает их кушать меньше?

> Если не секрет, какое кол-во ОЗУ сьедает ваш PHP-воркер в среднем?
60 MB

Данный вопрос очень сильно связан с конкретной задачей, которую выполняют Ваши воркеры. Например, если это рэсайзинг изображений — php тут вообще не нужен.
Спасибо за ответы.

>Зачем Вам 100 воркеров?
Количество запросов к воркерам в часы пик более 100 в секунду (при кэшировании). Конечно нельзя назвать это «высокими нагрузками», но 1 воркер может выполнять одну задачу одновременно, где среднее время выполнение задачи(получение, парсинг страницы и проход по некоторым УРЛ страницы) — 2 секунды(до 60 секунд). Отсюда скорость системы зависит от параллельного выполнения задач.

>Чем воркеры «в формате TCP» принципиально отличаются от воркеров «в формате I/O»? И что побужтает их кушать меньше?
Вы правы, ничем. Это я «в поисках решения» сказал)

>. Например, если это рэсайзинг изображений — php тут вообще не нужен.
Нет, ресайзинга и ничего такого нет.
> получение, парсинг страницы и проход по некоторым УРЛ страницы
Это можно сделать на nodejs?
Зависит от соотношения Network/Processor — если это 9/1 (как у меня), то будет раз в 10 быстрее (это для одного процесса).
Но самое главное — это память. Если грамотно написать (а в nodejs это не так легко), то процесс будет кушать не более 100 МБ. 4 ядра — 4 таких процесса. Опять же, зависит от логики самой программы. Если это краулер, тогда зависит от размера страниц и количества одновременной обработки — это можно регулировать.
Спасибо, попробую на nodejs переписать воркеров.

На простых задачах(там, где не надо проходить по ссылкам внутри страницы) NodeJS в один поток делает по скорости пхп, запущенный параллельно через spawn.child. Попробую на более сложных, в 4 потока и регулировать, как вы посоветовали.
Only those users with full accounts are able to leave comments. Log in, please.