Comments 173
Столько информации, много очевидного, мало деталей интересных реализаций. Лучше было бы по частям описывать интересные загогулины и как вы их обошли, и на какие грабли наступили. Но доходчиво. А то галопом по Европам.
Ну и это… зарекламили статью как презентацию ридера. И где он?
Ну и это… зарекламили статью как презентацию ридера. И где он?
Изначально так и начал писать, но получилось слишком растянуто.
Особо детально описал работу бекграунда и очередей, поскольку считаю это более интересным.
А вообще, так и хотелось — передать все в общих чертах, не углубляясь сильно в детали. Слишком много для одной статьи.
Я же сказал, что презентация будет потом, а эта статья несет чисто технический характер…
Особо детально описал работу бекграунда и очередей, поскольку считаю это более интересным.
А вообще, так и хотелось — передать все в общих чертах, не углубляясь сильно в детали. Слишком много для одной статьи.
Я же сказал, что презентация будет потом, а эта статья несет чисто технический характер…
Прочитал, все, весь текст, облизывался на новый ридер и правда, где он?
На следующей неделе анонсируем его на хабре.
Ждем! Было бы круто, если бы в анонсе описали чем он круче 2 ридер-монстров этого времени — Гугл Ридер и Нетвайбс.
Ждете выходных? :)
привет робокопу от Кира ;)
Вы прочитали мои мысли и избавили меня от тяжкого бремени делать ридер самому.
Впрочем, я бы немного изменил систему подсчета TTL на следующий день, учитывая паттерн, сложившийся на завтрашний день недели и за прошлый месяц.
Еще одна очень нужная фишка — генерация RSS из всех фидов в данной папке, этакий миксер потоков.
И, пожалуй, как завершение, как вишенка на пирожном, нужна кнопка на любом сайте «добавить RSS-поток с этого сайта в читалку». Маленькая иконка, которая сэкономит время.
Впрочем, я бы немного изменил систему подсчета TTL на следующий день, учитывая паттерн, сложившийся на завтрашний день недели и за прошлый месяц.
Еще одна очень нужная фишка — генерация RSS из всех фидов в данной папке, этакий миксер потоков.
И, пожалуй, как завершение, как вишенка на пирожном, нужна кнопка на любом сайте «добавить RSS-поток с этого сайта в читалку». Маленькая иконка, которая сэкономит время.
А про монетизацию использования приложения статья будет? Интересно было бы почитать.
Скажите, вам не становится страшно когда вы думаете как поддерживать такой зоопарк технологий?
Становится. Страшно.
Ну что же — удачи! :-)
почему было не использовать эрланг? зоопарк действительно дикий, вы бы сэкономили массу времени и сил, при этом система у вас еще сырая, по вашим же словам…
А Вы использовали?
да, оно идеально ложится как раз на связанное с очередями, воркерами, интерактивной отладкой, масштабированием и прочим
кстати, например, для монго есть библиотека
интегрируется с другими языками через безопасные «порты»
я писал кравлер, и после это писать такого рода сервера на чем-лтбо еще видится мне садомазохизмом )
кстати, например, для монго есть библиотека
интегрируется с другими языками через безопасные «порты»
я писал кравлер, и после это писать такого рода сервера на чем-лтбо еще видится мне садомазохизмом )
Название конфликтует с лозунгом «Без велосипедов».
Ну, по поводу заголовка и велосипедов очень четко подмечено.
Говоря «Rss ридер» я имею ввиду техническую характеристику, а вовсе не специфику проекта. Ведь это разные вещи, верно?
Говоря «Rss ридер» я имею ввиду техническую характеристику, а вовсе не специфику проекта. Ведь это разные вещи, верно?
Вот этим.
habrahabr.ru/blogs/startup/89406/
habrahabr.ru/blogs/startup/89406/
Аггрегатор и ридер совсем разные программы. Тут явно много времени было уделено интерфейсу. Но 2000 ч.часов это сильно да. 250 рабочих дней по 8 часов. Если не ошибаюсь Торвальдс ядро линукса быстрее написал
А как же eventr?
Когда задача выбирается из очереди, на нее ставится Lock (для блокировок используется memcache)
вот он FAIL
Посоветуйте
Например ново-модный Redis, он поддерживает транзакци
Спасибо, ковырну
а это вы не рассматривали? nodejs.ru/362
Почитал, очень интересно и просто… и поздно :)
Спасибо, буду иметь ввиду.
Очереди переделаю на Redis.
Спасибо, буду иметь ввиду.
Очереди переделаю на Redis.
Почему бы не заточенными решениями типа RabbitMQ (или ZeroMQ если гарантия доставки не важна)?
AMQP/RabbitMQ — по мне так хорошее решение для очередей.
Очень надёжное и быстрое, используем много где.
Кстати, есть github.com/ry/node-amqp
Очень надёжное и быстрое, используем много где.
Кстати, есть github.com/ry/node-amqp
Только это не привычные по rdbms транзакции, а скорее балковое исполнение команд.
В свое время 5 лет назад на заре расцвета AJAX писал RSS-ридер для нашего портала — rss.i.ua
Поэтому проблемы с тем, что приходит в RSS-потоке и в каком виде — нуууу очень понимаю :)))) Костылей там приходится очень много повставлять.
Поэтому проблемы с тем, что приходит в RSS-потоке и в каком виде — нуууу очень понимаю :)))) Костылей там приходится очень много повставлять.
меня напрягает такое обилие слэнга (зачастую сугубо индивидуального, видимо) — это добавляет неоправданной сложности. часто это является следствием того, что желание похвастаться довлеет над желанием поделиться знанием.
а так ниче. раскрыты некоторые грабли которые нас ждут при использовании новомодных штучек.)
а так ниче. раскрыты некоторые грабли которые нас ждут при использовании новомодных штучек.)
многа букаф, ниасилил
Не нужно считать проблемой то, что собьется какой-нибудь счетчик.
Поддерживаемые MongoDB атомарные функции решают эту проблему. Пример: {$inc:{counter:1}}
А вообще довольно объёмная работа. Мне кажется, что вам помог бы нескольконедельный отдых после такой дикой нагрузки, ну там Карелия с байдарками, или ещё какие-нибудь прелести активного отдыха далеко от дома.
Удачи!
Мобильную версию (Android, iPhone, iPad) не делали?
А переписать mongomapper на js это велосипед? я вот тут начал ввиде плагина к express писать, только там проблема возникла пока с jspec либой. Проект еще сырой документации нету, но вот написать mongomapperjs очень хочется.
>Без велосипедов
это вычеркниет. ведь ваш рсс-ридер — сам по себе велосипед.
это вычеркниет. ведь ваш рсс-ридер — сам по себе велосипед.
Такой объем лучше по частям. А на ридер я бы с удовольствием взглянул:)
> backward-capability
Всётаки backward-compatibility
Всётаки backward-compatibility
Очень вкусно описал процесс, спасибо.
Где бы теперь подписаться на анонс ридера, чтоб не пропустить ненароком?
Где бы теперь подписаться на анонс ридера, чтоб не пропустить ненароком?
Анонс появится либо в разделе «Стартапы».
Называется Eventr.
Спасибо.
Называется Eventr.
Спасибо.
www.eventr.com/
Он? =)
Он? =)
this is fucking awesome
Вот это да!
Я и сам недавно заморачивался многим из вышеперечисленного (и сейчас заморачиваюсь) — node.js, MongoDB, сервер очередей написал тоже, правда более примитивный. На этом действительно можно делать очень интересные вещи ))
Я и сам недавно заморачивался многим из вышеперечисленного (и сейчас заморачиваюсь) — node.js, MongoDB, сервер очередей написал тоже, правда более примитивный. На этом действительно можно делать очень интересные вещи ))
Вы очень крутой! А еще перфекционист.
Жаль, что подобный подход к работе конфликтует с личной жизнью и всякими увлечениями.
Расскажите, что вас мотивирует?
Жаль, что подобный подход к работе конфликтует с личной жизнью и всякими увлечениями.
Расскажите, что вас мотивирует?
По поводу перфекционизма, меня очень сильно впечатлил вот этот доклад:
vimeo.com/10922497
Мотивирует, наверное, то же, что мотивировало дядечку Эйнштейна, и еще другую тысячу психов по всей планете.
vimeo.com/10922497
Мотивирует, наверное, то же, что мотивировало дядечку Эйнштейна, и еще другую тысячу психов по всей планете.
Результат бы посмотреть.
Заметил перфекциониста — и это офигенно похвально! Таких весьма совсем не очень. Сам сейчас пишу биллинг на Nodejs и mongodb, плюс API на стороне ZF. И мне нравится серверный JS!
Народ, включайтесь в группу Nodejs и остальные похожие по теме группы на гугле — русских там 1.5 человека пока.
Народ, включайтесь в группу Nodejs и остальные похожие по теме группы на гугле — русских там 1.5 человека пока.
по поводу велосипедов
что конкретно может заставить пользователей уйти с Google Reader?
что конкретно может заставить пользователей уйти с Google Reader?
Смотря каких. Их там много.
В другой статье все расскажем.
В другой статье все расскажем.
Могу посоветовать добавить поддержку Digest-авторизации, этого так не хватает в GR для чтения подзамочных записей ЖЖ.
в жж подзамок можно читать через user:pass@livejournal…
Чем обоснован отказан от реляционных баз данных в пользу монго? Ридер проектируется с расчетом на гигантские нагрузки или вы просто поддались модному тренду «noSQL»? :)
Повелся на модный тренд. Но если будут гигантские нагрузки — буду только рад :)
А Вы лучше скажите, зачем использовать реляционную бд, если ее «реляционность», в итоге, используется на 10%? (в нашем случае)
+ schema-less
+ легкие миграции
+ data-driven queries (очень нравится)
+ нативный шардинг, в случае чего
+… можно перечислять
А Вы лучше скажите, зачем использовать реляционную бд, если ее «реляционность», в итоге, используется на 10%? (в нашем случае)
+ schema-less
+ легкие миграции
+ data-driven queries (очень нравится)
+ нативный шардинг, в случае чего
+… можно перечислять
Почитайте тут
zabivator.livejournal.com/412053.html
zabivator.livejournal.com/412053.html
Спасибо, прочел.
«Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.» — про меня
«Ниша NoSQL — высоконагруженные сайты, вырастающие из стартапов.» — надеюсь, про наш стартап
А Вы, в свою очередь, посмотрите вот этот доклад:
www.infoq.com/presentations/Facebook-Software-Stack
И оцените, как фейсбуку приходится использовать MySQL.
«Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.» — про меня
«Ниша NoSQL — высоконагруженные сайты, вырастающие из стартапов.» — надеюсь, про наш стартап
А Вы, в свою очередь, посмотрите вот этот доклад:
www.infoq.com/presentations/Facebook-Software-Stack
И оцените, как фейсбуку приходится использовать MySQL.
Спасибо, посмотрю.
Буду колупать Redis на днях. Скорее всего, прикручу его к node и на этом пока остановлюсь.
Буду колупать Redis на днях. Скорее всего, прикручу его к node и на этом пока остановлюсь.
мы вот сделали такую систему на базе Gearmand и Zend_Reader — работает все отлично, уже в продакшине почти полгода. Единственная проблема — всякая фигня непридсказуемая в лентах. Например, многие ленты по особенному трактуют поле даты новости и она часто неверно понимается парсером.
вот читаю такие посты и понимаю что я очень много еще не знаю мягко говоря.
Ждем читалку
Ждем читалку
Очень хотелось бы взглянуть на ваш карказ над ZF.
Описание контроллера и менеджеров — один-в-один supervision tree из Erlang'a (gen_supervisor, gen_server) Это не упрек в велосипедности :) Просто показатель того, что рано или поздно разработчики приходят к похожим архитектурным решениям.
По поводу ридера главный вопрос — HTTP Digest Authentication, которая есть, например, в livejournal'е Ни один онлайн сервис, насколько знаю, не поддерживает ее, а хотелось бы :)
По поводу ридера главный вопрос — HTTP Digest Authentication, которая есть, например, в livejournal'е Ни один онлайн сервис, насколько знаю, не поддерживает ее, а хотелось бы :)
Спасибо, очень интересно было читать!
PubSub прикручивайте — он (с точки зрения ридера) простой как сапог, зато позволяет для фидов, что его поддерживают, практически мгновенно доставлять сообщения, в обход общей очереди feed pull-а.
PubSub прикручивайте — он (с точки зрения ридера) простой как сапог, зато позволяет для фидов, что его поддерживают, практически мгновенно доставлять сообщения, в обход общей очереди feed pull-а.
собирался писать ридер для себя и очень рад, что, наверное, не придётся :)
Будет ли импорт/экспорт фидов в OPML? будет ли HTTP Digest Authentication? Было бы очень неплохо
Будет ли импорт/экспорт фидов в OPML? будет ли HTTP Digest Authentication? Было бы очень неплохо
Добавьте в него IMAP.
Единственный удобный для меня ридер — это версия Google Reader для айфона, по адресу google.com/reader/i/, она и легкая, и удобная, и не перегружена ничем лишним.
насколько кртитичная информация хранится в очереди memcacheq? я имею ввиду — что будет, если вдруг случайно очередь потеряется?
«Все, что я имел с самого начала, это небольшой каркас, делающий работу с zf слегка удобней. » А каркас ваш или это какое-то общедоступное решение?
а зачем PHP здесь?
что мешает все-все-все на node.js сделать?
что мешает все-все-все на node.js сделать?
Экспорт данных в FB2 или LRF будет?
года два назад делал свой ридер. Все мечты разбились когда увидел fav.or.it(который загнулся по неизвестным причинам) и обомлел. А вы имея перед глазами gr и netvibes работали почти год, поэтому мой вам поклон.
Спасибо за статью и всем за коменты!!! Теперь точно не высплюсь (( Пошел ковырять node.
Каркас для ZF псмотреть бы… (скромно)
Каркас для ZF псмотреть бы… (скромно)
«Так же, существует WorkerPhp.js, который запускает php-cli как child-process и общается с ним на json»
объясните пожалуйста, а как вы держите эти PHP не закрытыми? черех php-fpm?
объясните пожалуйста, а как вы держите эти PHP не закрытыми? черех php-fpm?
и это наверное у вас не php-tcp сервер, я правильно понимаю?
Да, где-то так:
while ($request = fgets($this->_stdin)) {
$this->handleData($request);
}
Т.е. все-таки воркеры в режиме tcp-серверов, открываете их на портах и общаетесь с ними?
У меня проблема выбора или php-fpm или в качестве tcp-серверов воркеры пускать, что вы бы посоветовали?
У меня проблема выбора или php-fpm или в качестве tcp-серверов воркеры пускать, что вы бы посоветовали?
Это не tcp, это простой std I/O. Работает замечательно, поскольку основной упор времени именно на выполнение задач, передача данных в моем случае — спички.
Помоему, tcp необходим только в том случае, когда нужно общение между разными серверами.
Помоему, 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 гигабайта(что не предел из-за динамического кол-ва воркеров и динамически-меняющегося необходимого кол-ва ОЗУ отдельно взятому воркеру).
Справедливости ради надо сказать, воркеры в формате 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 воркеров? У меня максимум 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 тут вообще не нужен.
Нет, ресайзинга и ничего такого нет.
>Зачем Вам 100 воркеров?
Количество запросов к воркерам в часы пик более 100 в секунду (при кэшировании). Конечно нельзя назвать это «высокими нагрузками», но 1 воркер может выполнять одну задачу одновременно, где среднее время выполнение задачи(получение, парсинг страницы и проход по некоторым УРЛ страницы) — 2 секунды(до 60 секунд). Отсюда скорость системы зависит от параллельного выполнения задач.
>Чем воркеры «в формате TCP» принципиально отличаются от воркеров «в формате I/O»? И что побужтает их кушать меньше?
Вы правы, ничем. Это я «в поисках решения» сказал)
>. Например, если это рэсайзинг изображений — php тут вообще не нужен.
Нет, ресайзинга и ничего такого нет.
> получение, парсинг страницы и проход по некоторым УРЛ страницы
Это можно сделать на nodejs?
Это можно сделать на nodejs?
Да. Скорость будет больше?
Зависит от соотношения Network/Processor — если это 9/1 (как у меня), то будет раз в 10 быстрее (это для одного процесса).
Но самое главное — это память. Если грамотно написать (а в nodejs это не так легко), то процесс будет кушать не более 100 МБ. 4 ядра — 4 таких процесса. Опять же, зависит от логики самой программы. Если это краулер, тогда зависит от размера страниц и количества одновременной обработки — это можно регулировать.
Но самое главное — это память. Если грамотно написать (а в nodejs это не так легко), то процесс будет кушать не более 100 МБ. 4 ядра — 4 таких процесса. Опять же, зависит от логики самой программы. Если это краулер, тогда зависит от размера страниц и количества одновременной обработки — это можно регулировать.
Sign up to leave a comment.
2000 часов в одиночестве, или как был сделан RSS reader / Я робокоп