По просьбам хабралюдей выкладываю короткий технический отчет.Напомню, Eventr – это web-сервис, в котором можно удобно читать RSS-ленты, в два клика обмениваться, делиться интересными записями с другими, вести свой блог.
Мы стартовали днем в воскресенье, 11-го июля, через час легли под хабраэффектом. Собственно, наши волшебные заклинания и цифры под катом.
О чем будет сказано:
- Некоторые технические сложности
- RSS/Atom читалка, цифры
- Хабраэффект, цифры
- Грабли
- 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.
Мы продолжаем работать над повышением надежности и удобства сервиса.
Спасибо.
