- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Rails Scale: 1000 запросов в секунду презентация
Содержание
- 1. Rails Scale: 1000 запросов в секунду
- 2. Задача: оптимизация приложения вконтакте
- 3. 30 тыс пользователей до 9 секунд на
- 4. Более 2-х млн пользователей 25 мс на
- 5. Ежедневная смена требований Экспоненциальный рост нагрузки Поровну
- 6. Что оказалось важным в нашем случае
- 7. Грамотный менеджер «Щасспрошу» завалит проект Персонал
- 8. Системный администратор. Получше, чем «aptitude-джан» Персонал
- 9. Наша команда злых марсиан! http://evilmartians.ru/ Персонал
- 10. Волшебных гномиков нет.
- 11. Нет их даже в MongoDB и memcached
- 12. pgpool — master-master медленный memcached — нечего кешировать Сразу выкинули
- 13. Ruby on Rails — нужна гибкость PostgreSQL — часто меняется схема RabbitMQ — задержка записи внешний инструментарий Оставили
- 14. Что мы делали
- 15. Без него никуда Догадки не работают newrelic.com Фоновые задачи очень важны Профилирование
- 16. Место на дисках Упавшие серверы Длины очередей Ночной дежурный (?) Мониторинг
- 17. Нужны реляционные выборки Часто меняются критерии PostgreSQL
- 18. Много данных рядом — плохо Нам повезло с
- 19. Меньше всего проблем Zero-downtime deploy с unicorn-ом Плохая поддержка шардинга Необходимость RabbitMQ Ruby on Rails
- 20. Самая быстрая часть проекта Оказался индикатором состояния Мучительное восстановление RabbitMQ
- 21. Rails do scale Масштабирование — вопрос предметной области У вас всё будет по-другому Выводы
Задача: оптимизация приложения вконтакте
Слайд 330 тыс пользователей
до 9 секунд на запрос
5 серверов
надо опустить время ответа
до 500 мс
Вводные
Слайд 4Более 2-х млн пользователей
25 мс на запрос
14 серверов
40K RPM и 20
млн записей в сутки
Результаты
Слайд 5Ежедневная смена требований
Экспоненциальный рост нагрузки
Поровну записи и чтения
Сделать быстро, дешево и
приемлемо
С чем столкнулись
Слайд 13Ruby on Rails — нужна гибкость
PostgreSQL — часто меняется схема
RabbitMQ — задержка записи
внешний инструментарий
Оставили
Слайд 17Нужны реляционные выборки
Часто меняются критерии
PostgreSQL быстр и удобен
Индексы — основной дисковый IO
SQL
база
Слайд 18Много данных рядом — плохо
Нам повезло с логикой выборок
Шардинг: user_id % 100
Надо
планировать заранее
Шардинг
Слайд 19Меньше всего проблем
Zero-downtime deploy с unicorn-ом
Плохая поддержка шардинга
Необходимость RabbitMQ
Ruby on Rails
