Технический отчет запуска Eventr.com, цифры

    image По просьбам хабралюдей выкладываю короткий технический отчет.
    Напомню, Eventr – это web-сервис, в котором можно удобно читать RSS-ленты, в два клика обмениваться, делиться интересными записями с другими, вести свой блог.

    Мы стартовали днем в воскресенье, 11-го июля, через час легли под хабраэффектом. Собственно, наши волшебные заклинания и цифры под катом.

    О чем будет сказано:
    1. Некоторые технические сложности
    2. RSS/Atom читалка, цифры
    3. Хабраэффект, цифры
    4. Грабли
    5. Mongodb, nodejs, redis

    На момент среды — 3 дня со старта


    3,050 пользователей
    ~200 пользователей онлайн, которые читают в среднем 5 записей в секунду
    22,340 потоков (из них 18,546 — внешние rss/atom фиды)
    ~25 фидов в секунду обновляется бекграундными серверами
    811,614 новостей (включая user generated)
    727 импорта в общей сложности на 47,032 фидов (не учитывая повторы)
    207 обработанных фидбеков пользователей

    Запуск


    Основные технические аспекты я описывал ранее в другой статье. С тех пор кое-что изменилось, в «зоопарк» добавился redis и capistrano.

    Основная сложность — пустая база данных. Нужно было выдержать неопределенное количество OPML импортов с неопределенным количеством фидов, а самое главное — в ограниченный отрезок времени. Спрогнозировать нагрузку оказалось нереальной задачей, поэтому мы просто сцепили зубы и смотрели, как растет LA и размер очередей на наших серверах.

    На данный момент, самое сложное для системы — это поддерживать более 18 тысяч внешних источников в актуальном состоянии. А также вести индивидуальный учет прочитанных записей для каждого пользователя. Все остальное — мелочи жизни.

    Хабраэффект, цифры


    График регистраций / OPML импортов / общего количества фидов


    На этом графике показано количество импортов, с шагом в 10 минут. Рядом рост пользователей и общее количество фидов в системе. Большую часть мы вытянули в первый день.
    Последующие импорты использовали уже существующие фиды.

    Другие цифры


    Mongodb:
    Всего объектов: 1,028,554
    Общий размер: 3,17 GB (из них 2,76 GB контент из фидов)
    Размер индекса: 465 MB
    Кушает CPU: ~2%
    Кушает RAM: 3,2 GB
    Mongo время на комплексную выдачу средней страницы (без кеширования): 0,3 sec
    Блокировки практически не чувствуются.

    Nodejs:
    Кушает памяти: ~20 MB
    CPU вообще не ест.

    Грабли


    Слабые сервера. Изначально мы стартовали с двух физических серверов и 12-ти openvz виртуалок. Идея простая: растет нагрузка — покупаем новое железо, мигрируем уже готовые образы — весьма удобно.
    Первая ошибка — web инстанс (nginx, php-fpm) на более слабом сервере. Практически сразу — LA 40, после чего, он просто перестал отзываться на ssh. Перенос его на более мощный сервер занял полчаса.

    Mongodb репликация под нагрузкой. Тот монго slave, который находился на более слабом сервере, не успевал читать oplog (для синхронизации), что привело к потере версии статики (которая хранилась на тот момент в монго). В последствии, часть пользователей увидели очень красивый eventr без стилей и картинок. Перенесли версию статики в redis.

    Системные и пользовательские очереди на одном сервере. Чем больше фидов в системе, тем больше ресурсов нужно на перманентное их обновление (для поддержания актуальности). Через полчаса работы сервиса, очередь напрочь забилась фоновыми обновлениями и вытеснила пользовательские запросы в виде импортов или отдельного добавления внешних фидов. На тот момент, в очереди было в среднем от 5 до 15 тысяч задач.
    В самое горячее время, пока нам везли новые сервера, мы подключили свои ноутбуки к очереди — помогало :) Тем временем, пользователи с импортами негодовали.
    На данный момент, у нас четыре бекграундных сервера. Три из них — для фонового обновления, один — для пользовательских очередей. Теперь обработка более 18 тысяч фидов никак не влияет на скорость работы интерфейса и пользовательских действий вроде импорта.
    После того, как установили новые сервера, пришлось их очень серьезно напрячь, чтобы быстро разгрести накопленную очередь. На тот момент, скорость достигла 100 потоков/секунду. Сейчас для поддержания всей базы хватает 25 в секунду.

    Zend_Date. Оказалось, его вызовы занимали 70% всего времени на рендеринг шаблонов. Сам в шоке. Так же, Zend_View partial и placeholder — от них вообще отказались.

    Приятные моменты


    Mongodb
    Показал очень приятные цифры. Индексы работают, как часы. Удобное администрирование, масштабирование, и, самое главное — миграции.

    nodejs
    Очень резкий. Удобная и быстрая разработка. Идеальный garbage collection и отказоустойчивость. Учитывая, что на нем работает весь бекграунд (подробнее читайте в предыдущей статье), могу называть nodejs самым приятным, что встречал за все время разработки. Единственное — не очень удобный интерфейс работы с mongodb. С redis удобно.

    redis
    На нем: кэш, очереди, блокировки. Супер быстрый и очень удобный. Так же, для общения между серверами испольуется его PubSub. Идеально подходит для риалтаймовых вещей. В php испольуем редиску, отдельное спасибо Shumkov за саппорт.

    capistrano
    Очень советую — всем. Деплой на 10 инстансов из рутинной ручной работы превращается в приятное созерцание разноцветной консольки, которая все делает за тебя.

    zabbix
    В сравнении с nagios, для меня он оказался удобнее. Очень легко добавлять специфические триггеры и получать по ним красивые графики риалтайм.

    В общем


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

    Мы благодарны всем тем, кто прислал фидбеки, а также всем пользователям первой беты eventr.com.
    Мы продолжаем работать над повышением надежности и удобства сервиса.

    Спасибо.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 93

      0
      хотелось бы подробностей по поводу физических серверов, какая конфигурация?
        +2
        1. core2duo, 4GB, 2x320GB (RAID1)
        2. quadcore, 8GB, 2x500GB (RAID1)
        3. quadcore i5, 8GB, 2x500GB (RAID1)
        4. quadcore i5, 8GB, 2x500GB (RAID1)
        • UFO just landed and posted this here
            0
            да
        +3
        >Zend_Date. Zend_View partial и placeholder
        Да-да, веселые проблемы с ними при нагрузках
          0
          Первая ошибка — web инстанс (nginx, php-fpm) на более слабом сервере

          то есть это связка не подходит под высокие нагрузки именно на слабом железе? либо вообще не подходит под хайлоад?
            +5
            nginx, php-fpm — отличная связка.

            Ошибка была в том, что мы изначально не запустили его на более мощном железе, хотя оно у нас было.

            Оптимизируй, не оптимизируй, кешируй — PHP все равно жрет, в силу своей архитектуры.
            0
            у вас ошибка еще в том что у вас вертикальная масштабирование, горизонтальное дает бОльший прирост производительности. ну это если деньги конечно на сервера. так же непонятно почему не было сделано нагрузочное тестирование проекта. вы пишите о том что база пустая — так нужно было закинуть туда данных на 100-200к пользователей, на каждого по 10-20 фидов и потестировать как это все работает.
              +2
              Web перенесли на более мощный сервер — единственное «вертикальное» действие, сделанное нами.

              1. Добавили web2 — горизонтально
              2. Разнесли очереди на четыре сервера — горизонтально
              3. Mongodb будем масштабировать только горизонтально
              4. Redis — горизонтально

              Нагрузочное тестирование проводилось, но не дало особых результатов (читайте последний абзац в статье). Зачем тратить время и деньги на фигню, если можно протестировать систему с реальными людьми, и получить реальную статистику?
                +7
                тестирование нагрузочное, интерграционное, регрессивное, юнит это далеко не фигня… вы заставили пользователей видеть ваши сбои. вы заставили пользователей быть нагрузочным тестированием.

                правильное тестирование ВСЕГДА дает результат, а вы его сделали наверное плохо. в итоге вы легли всего на 3к юзеров. это вообще копейки.

                я думаю что при более серьезном подходе к тестированию вы бы могли выдержать 100-200к юзеров, либо были бы готовы к контролируемым перегрузкам на таких обьемах.

                3к юзеров это не хабраэффект. это детская нагрузочка.
                  +1
                  Хабраэффектом были не 3000 юзеров, а скорее сотни фидов, которые эти пользователи стали импортировать из google reader и просто добавлять руками, насколько я понял из статьи.
                    +1
                    Вы правы. Тысячи фидов.
                      0
                      и что разработчик по-вашему не понимал что 1 юзер может загрузить больше одного фида ?:) надо было ориентироваться минимум на 10 фидов на одного юзера. итого 30к фидов. тестировать надо было :) но разработчик считает что тестирование это фигня. это его право.
                        0
                        Тут, имхо, дело не в отсутствии тестирования, а в слишком пессимистичном определении оптимистичного количества пользователей (и/или их поведения). Я вот зарегался без особых проблем, и не на один фид не подписался (поскольку разочаровался в «традиционных» ридерах, включая, но не ограничиваясь, гугловским, а за эти несколько дней фидов, достойных подписки, не встречал — хабр и подобные ресурсы считаю нужным читать вживую, через рефреш в постоянно открытых вкладках) — это же не значит, что надо ориентироваться на меня?
                          0
                          В Eventr есть один главный момент — люди. Я лично читаю 50 потоков, из них 40 — люди, и только 10 фидов. И то, из этих 10ти — 5 мои внешние блоги, для копирования в свой ивентр поток.

                          Вот реальная практика использования Eventr. Это офигенно удобно. Но должно пройти время, пока люди это прочувствуют.
                    0
                    да кстати — веб лучше балансировать через днс, поставить 2-3 сервера — им по ипу каждому, и пусть днсы где висят ваши домены через свои round-robin алгоритмы балансируют нагрузку между 3-я серверами. вышло бы лучше и эффективнее
                      0
                      nginx upstream разумней
                        +1
                        нет не разумней, вернее не всегда. простой пример
                        у вас 100к коннектов в секунду и 51 сервер — 1 под нгникс с upstream и 50 бекендов — бекенды успеют обработать такую нагрузку например. а вот сервер нгникс не сможет выдержать такой поток — он будет бутылочным горлышком.

                        поэтому разумнее использовать балансировку на днс — они раскинут 100к коннектов на 51 машину — и все обработается прекрасно.
                          +2
                          вы где-нибудь видели балансировку по 50-ти адресам? =)
                          скорее, при действительно большой нагрузке, схема будет выглядеть как балансировка днс'ом на пару хостов + nginx upstream с бекэндами

                          а теперь представьте, 1-5 нод «легли», ДНС будет отправлять туда — там глухо, сайт не доступен
                          nginx умнее, он отправит на другую ноду
                            0
                            а кто вам сказал что днс не умеет определять мертвые ноды? ставится обычное слежение за нодами раз в минуту — а если 1-5 нод легли — убираем их из днс на время пока не поднимутся.
                            далее все же зависит от нагрузки на сервера нгинкс — само собой один может обслуживать 5-6 бекендов если силенок хватит. а вот если не хватит — будет плохо.

                            + резервирование нод никто не отменял. хотя такие масштабы и мощности применяются в проектах которые стоят очень дорого.

                            я лишь хотел показать что нгинкс при большой нагрузке и много бекендов к нему может стать бутылочным горлышком и нужно применять другие схемы балансировки
                              +1
                              Чем не нравится балансировка через DNS — «тупые клиенты», кэширующие ответы DNS, да ещё использующие только первый IP из ответа — нода умерла, юзер жмёт «обновить» (или скрипт повторяет запрос), но ответа не получит, пока нода не поднимется, хотя ещё 50 нод стоят и ждут когда же их кто-нить запросит
                                0
                                почитайте спецификацию wininet — и вы увидите что при попытке достучаться на домен будут перебирать все ипы которые выданы в днс.

                                например у нас есть 50 нод — мы в резолв домены выдаем 3-5 — итого
                                1.1.1.1
                                1.1.1.2
                                1.1.1.3
                                1.1.1.4
                                1.1.1.5

                                так вот если первая нода недоступна — вининет автоматически будет коннектится на второй ип
                                вероястность того что все выданные 5 нод неработащие при управляемом днс составляет 1/50 ^5 — т.е вероятность неработы каждой ноды в степени 5.

                                согласитесь — вероятность очень мала
                                  +1
                                  Осталось только, всего то, заиметь 50 нод. Эдак, на $20,000.
                                    0
                                    ну все зависит от серьезности проекта, и финансовых возможностей его хозяев. все выбирает под задачу и нагрузки индивидуально.
                                      0
                                      А где вы такие дешевые ноды берете(по $400)?
                                      Кстати на какой площадке сервера держите?
                                        0
                                        Ой, неправильно посчитал… получается где-то от 50к до 70к. короче, какая разница :)

                                        ukrindex, ukrtelecom
                                      0
                                      В случае, если разработчик клиента следовал спецификации :) В популярных браузерах наверняка так, но встречалось, что на старый IP ещё неделями приходили запросы от, наверное, всяких грабберов и автосабмиттеров (хотя два IP выдавалось перед этим с месяц)
                              0
                              его и используем сейчас
                          +1
                          Capistrano, конечно, хорош.

                          Но я бы советовал вам использовать Chef. Для горизонтального развёртывания очень удобно.

                          jztalk.com/blogger/2010/03/05/automated-deployment-systems-push-vs-pull/
                            0
                            + Puppet
                            +4
                            Eventr находится сейчас в закрытом бэта-тестировании. Это не релиз. Просим пользователей отнестись с пониманием, если что-то не работает. Мы знаем и исправляем.
                              0
                              Спасибо, очень интересно :) Такой вопрос — если бы знали заранее, как оно будет работать, переписали бы веб-инстанс целиком на node?
                                0
                                Нет, бизнес-логику на node писать не удобно — мое мнение.
                                  0
                                  попробуйте связку haxe-node.js
                                  groups.google.com/group/haxe-nodejs/web/haxe-node-getting-started

                                  очень хороша.
                                  • UFO just landed and posted this here
                                      +1
                                      это мне вопрос или товарищу выше? ))
                                        +1
                                        NodeJS еще очень сырой для реализации приложений со сложной бизнес-логикой. Его асинхронные преимущества не могут не радовать, но их, при этом, сложнее тестировать, т.е. любой кусок кода становится неоднозначным. Во время разработки нужно анализировать больше зависимостей, чем в том же линейном php.
                                        В вашем случае, преимущество nodejs как раз не в риалтайме, а в ресурсах и персистентности. Вы ведь можете легко масштабировать ваши приложения по мере возрастания нагрузки. Например, все 20 приложений могут работать на одном nodejs инстансе (один другому не мешая), в последствии, количество nodejs процессов можно увеличивать, раскидывать по физическим серверам, повышая при этом производительность. И даже порты разные не нужны, ведь для этого есть хосты.
                                        Однозначно — если ваши приложения имеют нетривиальную модель, с nodejs вам будет сложновато организовать удобную инфраструктуру… имхо, JS код вообще сложно организовать :) Но тут уже все зависит от ваших архитектурных талантов.
                                          +1
                                          Кое-что забыл:
                                          Не знаю, как с MySQL, но с mongodb из nodejs работать не очень удобно. Даже суперский mongoose, и тот сделан вообще не очевидно, хотя вроде бы и был создан для того, чтобы облегчить работу с mongo.
                                          Вот с redis, например, работать легко и приятно.
                                          • UFO just landed and posted this here
                                              0
                                              > какое-то небольшое приложение на Node.js, которое в асинхронном режиме запускает 1 из 20 приложений для обработку запроса, а вот оно уже в своей физической папке с всеми зависимостями лежит %)

                                              Именно так. А вот сами приложения — это по сути модули, которым передается дальнейшее упревление запросом.
                                              Но это в случае, если ваши приложения хоть в чем-то однотипные, конечно же.
                                    +1
                                    Апач как я полагаю вы вообще не используете?
                                      +4
                                      последнее время, всё чаще, необходимость в нём вовсе не очевидна
                                        0
                                        не используем
                                        0
                                        мне до сих пор не понятно почему eventr.com/username
                                        пишет «В этом потоке пока нет записей. Теперь, вы можете сохранять сюда записи с источников, которые читаете»
                                        А при этом записи в stream есть.

                                          0
                                          И вдогонку. Как все папки/потоки перенести в мой основной поток eventr.com/username? Можно ли сейчас такое?
                                            0
                                            Вероятно, Вы имеете ввиду поток «Все записи» (all items), где можно читать все обновления. Эта функция будет доступна ближайшие дни. Основной же поток для того, что бы репостить в него интересное с фидов.
                                              0
                                              Спасибо. А если я хочу, чтобы в моем основном потоке /username пользователи гости читали все мои rss' потоки, как такое провернуть? И можно ли будет в будущем?
                                            0
                                            Не совсем понятно, что Вы имеете ввиду, говоря «stream»…
                                          +1
                                          кто-то загрузил импорт на 832 фида О_о
                                            0
                                            С момента публикации статьи со скрежетом выполнилось 70 импортов общей сложностью в 4,458 фидов. Самое жестокое, что все они добавились практически одновременно.
                                              +2
                                              а чем он принципиально отличается от того же гугл-ридера? как вы собираетесь с ними конкурировать и как монетизировать проект?
                                                0
                                                Достаточно широкий ответ тут: habrahabr.ru/blogs/startup/98797/
                                                  +3
                                                  Для меня отличие от гугл-ридера в первую очередь — это русскоязычная команда разработчиков и продукт в бета-тестировании. Разве это не отличный шанс повлиять на создание удобного сервиса? :) А ребятам спасибо! Очень надеюсь что проект будет развиваться и приносить радость своим создателям :)
                                                    0
                                                    Жаль, что на вопрос о монетезации прямого ответа нет. Он может быть довольно неприятным — сужу по нашей команде: первое время всё бесплатно, потом будут варианты (пускай и не исключающие бесплатное использование основной функциональности, но с очень ограниченной поддержкой)
                                                      0
                                                      Вопрос монетизации уже подробно обсуждался в нашем проекте. Могу пока только сказать, что он будет весьма не стандартным. Но до этого нужно еще дорости.
                                                • UFO just landed and posted this here
                                                  • UFO just landed and posted this here
                                                    +9
                                                    Ради таких статей еще стоит захаживать на хабр :) Спасибо.
                                                      0
                                                      я так понимаю mongodb у вас в master-slave репликации. как будете дальше масштабировать? нормального механизма шардинга вроде у монго еще нет, планируется в версии 1.6. а вручную все данные неудобно переносить.

                                                      я пока смотрю в сторону Riak, там горизонтальное масштабирование очень прозрачно. добавляется новый нод и все. данные растекаются по нодам. единственный минус Riak по сравнению с MongoDB — не так удобно доставать данные :)
                                                        0
                                                        Mongodb у нас изначально был master-master, он полноценно не поддерживается, но покрывал наши нужды.
                                                        С момента, когда с ним начали происходить неведомые вещи (от нагрузки отставала синхронизация, а поскольку она двусторонняя, ее сложно восстановить), сделали master-slave.

                                                        Да, ограничений на шардинг достаточно, но в нашем случае, нужно будет шардить только одну самую большую коллекцию — Entry. Даже с этими ограничениями уже можем.

                                                        Возможно, мы будем использовать Riak для других целей. А пока что, mongodb отлично справляется со своей задачей. Даже слишком.
                                                        0
                                                        Мне сложно сказать, почему вас столько завязано инфраструктуры на поддержку такого проекта. Я делал пять лет назад rss.i.ua, который в пике спокойно справлялся с 40 000 потоков, 100 пользователями онлайн. Технологии простейшие — LAMP.

                                                        Сложно высчитать долю из общего железа, которую использует наш сервис, но ориентировочно это кусочек около 2% DB-сервера с MySQL, кусочек 3-5% Apache сервера для обновления потоков по частому крону, кусочек Apache-сервера для обслуживания клиентских запросов.

                                                        Единственное что, если у вас более интерактивная среда благодаря Node.js (постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?) — то это, конечно, большая нагрузка и более интересные технологии.

                                                        В любом случае, думаю, вы еще найдете много мест для оптимизации алгоритмов. Удачи с проектом :)
                                                          0
                                                          > который в пике спокойно справлялся с 40 000 потоков
                                                          сколько потоков в секунду вы обновляли?

                                                          Да, мест для оптимизации хватает.
                                                          Сейчас, одна из важных задач — определять мение читаемые потоки, чтобы снижать их приоритет. По моим подсчетам, можно повысить производительность в 10 раз.

                                                          > постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
                                                          не совсем так, но это мы будем делать совсем скоро.
                                                            0
                                                            > > который в пике спокойно справлялся с 40 000 потоков
                                                            > сколько потоков в секунду вы обновляли?

                                                            Такой цифры, так как потокам выдается динамический приоритет. Только мы используем приоритет не по читаемости, а по обновляемости. Минимум каждый поток обновляем раз в сутки. Да, это одна из хороших явно видных возможностей для оптимизации.

                                                            > > постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
                                                            >не совсем так, но это мы будем делать совсем скоро.

                                                            Хм, если это не полный интерактив, то по идее вам после оптимизаций должно хватить раза в 2 меньшего количества оборудования, чем сейчас.
                                                              0
                                                              > Такой цифры, так как потокам выдается динамический приоритет. Только мы используем приоритет не по читаемости, а по обновляемости. Минимум каждый поток обновляем раз в сутки.

                                                              У нас некоторые потоки обновляются каждые 5 минут, максимум — раз в час. Тоесть, за час все (уже 21 тысяча) проходят обновление — совсем другие цифры.

                                                              Ваши пользователи не жаловались на задержки обновления?

                                                              P.S. pubsubhubbub не за горизонтом, уже многие его используют, и мы тоже будем.
                                                                0
                                                                Не жаловались на задержки. Я думаю тут несколько причин, наиболее важные:
                                                                1) Кто пользуется ридером, тот подписан на несколько источников. И ему и так приходит при каждом просмотре много информации, ему еще несколько более новых статей ничего не меняют.
                                                                2) Пользователи не знают о задержках — они же ходят в рсс-ридер, а не на сайт.
                                                                  0
                                                                  Логично.
                                                                  Но важность некоторых новостей может исчисляться в минутах, как ни крути.

                                                                  Уже посчитали, 20% потоков можно обновлять в 5 раз реже, 60% — в 10 раз реже.

                                                                  Так или иначе, RSS скоро уйдет на второй план в Eventr. А родные потоки обновляются моментально.
                                                                    0
                                                                    Согдасен насчёт минут и потому для пары фидов пользовался самопальным клиентом, ходящим через список прокси (эти фиды серьезно относятся к слишком частым, чаще чем в соответствующих полях указано, обновлениям) выводящим только, что фид обновился (смотрю через браузер, набирая url в адресной строке).

                                                                    P.S. Кстати, а счётчики читателей различные вы корректно обновляете или все мы «под одним прокси ходим»?
                                                                      0
                                                                      Счетчики индивидуальные. И алгоритм их подсчета сложно назвать тривиальным.
                                                                  +1
                                                                  pubsubhubbub никогда не заменит поллинг

                                                                  Во-первых, паблишерам для этого надо делать более сложные телодвижения, чем просто rss-ленты формировать — а это ограниченное время программистов + деньги им, что могут себе позволить только крупные контент-проекты. Выгоду же получают вовсе не паблишеры, а подписчики. Большинство проектов не будет ради этого заморачиваться, разве что с готовыми CMS это будет идти «из коробки».

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

                                                                  В-третьих, система сложнее — pub/sub/hub — а это и немного больше сторон-участников, и протоколов-транспортов между ними

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

                                                                  Ну а тем более пока этой системой мало кто пользуется, нам остается в основном оптимизировать поллинг :)
                                                                    0
                                                                    Согласен на все 100.
                                                                      0
                                                                      > pubsubhubbub никогда не заменит поллинг
                                                                      может быть уже скоро заменит, трудно сказать — но вот вам такая статистика
                                                                      feedburner (google) поддерживает pubsubhubbub
                                                                      из 800ооо RSS фидов на нашем проекте (viigo.com) 25% были с feedburner
                                                                      т.е. как минимум 25% уже покрыты.
                                                                      Там кроме feedburner есть и другие крупные компании — так что я думаю что доля ещё больше и бужет расти
                                                                  0
                                                                  Пропустил слово в комментарии

                                                                  *Такой цифры нет
                                                                0
                                                                > Eventr работает в режиме Бэта-тестирования.

                                                                Бета. Б-е-т-а. Вторая буква греческого алфавита.
                                                                  0
                                                                  мм… все мы люди, спасибо))
                                                                  –4
                                                                  Зачем, если есть twitter?
                                                                    +4
                                                                    Зачем появился google, если был yahoo?
                                                                      0
                                                                      Зачем нужен twitter?
                                                                      +1
                                                                      У меня на сервере скрипт всего лишь раз в час получал rss с news.google.com по одному запросу, в итоге через некоторое время забанили (выдавал ошибку 503, а если подменять user-agent, то просит вводить капчу).
                                                                      Просто информация на случай, если будут жалобы на необновляющиеся rss новостей.
                                                                        0
                                                                        Проимпортировал, пробую зайти — показывает кота. Полдня уже. Кому жаловаться? Имя такое же.
                                                                          0
                                                                          Чиним.
                                                                          Это связано с тем, что у Вас есть папка, в которой более 50ти потоков внутри. В сестеме стоит ограничение — после следующего деплоя кот уйдет, а Вам прийдет автоматическое письмо.
                                                                            +1
                                                                            Извините, что поломал :) Такой я читатель.
                                                                          +1
                                                                          Уже писал вам, но повторюсь: очень нужны инструменты соц. рекомендаций для более эффективной фильтрации контента. А именно избранное и показ у каждой записи кол-во голосов, ну или кол-во репостов или и то и то.
                                                                            0
                                                                            Именно с этих слов и начался Eventr.
                                                                            Все еще будет, у нас планы на два года вперед ;)
                                                                            0
                                                                            «Zend_Date. Zend_View partial и placeholder»

                                                                            бугага, а у нас на pushme.to основной затык был в ini-читалке Zend'овской. Она занимала что-то типа 400ms на каждый запрос, ну т.е. запредельно много.
                                                                              0
                                                                              Мы тоже это обнаружили недавно. Сейчас phing-ом генерится php конфиг через var_export, и он отличненько укладывается в APC opcode. Еще кэшируем роуты.

                                                                              Вообще, блин, руки чешутся закэшировать весь Application вместе с Di к чертям. А вообще, в идеале, вообще не выключать php, чтобы он работал, как демон (он у нас так на бэкграунде работает). Но это мечты.

                                                                              Кстати, у архитектуры наших Zend приложений общие предки (Гоша) :)
                                                                                0
                                                                                Вот мы примерно так и сделали — весь zend*ini в APC. Правда, не через генерацию, а просто заполняем кеш, если там уже нет конфига. Один раз в 30 секунд я переживу 400ms парсинга конфигов. :)

                                                                                Еще у нас apc.stat=0. Когда деплоимся, то вызываем секретный URL, сбрасывающий все содержимое APC.
                                                                                  0
                                                                                  Тоже apc.stat=0, но мы его не сбрасываем, потому, что у нас каждый деплой идет в другую директорию (весь проект где-то 20MB весит в памяти).
                                                                                  А еще у нас один include_path, переопределенный Zend_Autoloader и ни одного require_once — для того, чтобы использовать только абсолютные пути.
                                                                                  Кстати, если apc.stat=0, при удалении файла, он это замечает. Тоесть, всетаки, смотрит сволочь в файловую систему.
                                                                                  Еще пробовали загнать весь код проекта в ramfs — дало копейки, отказались.
                                                                                  0
                                                                                  Если вы начали думать об этом, то пора уже выбрать другой стек.

                                                                                  Я всё же попробовал бы переписать на Node.JS/Express или на Ruby/Sinatra.
                                                                                    +1
                                                                                    Переписывать можно бесконечно…
                                                                                    Главное — продукт. А все остальное — нюансы.
                                                                                0
                                                                                Ну, может быть, конечно, социализация — это и здорово, но особых отличий от шаринга в гуглочиталке.
                                                                                И несколько странный интерфейс, почему нельзя было сделать хоть минимум настроек? При попытке увеличить шрифт интерфейс расползается просто в ничто, печально :(

                                                                                Only users with full accounts can post comments. Log in, please.