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