1. Rails Scale: 1000
запросов в секунду
Макс Лапшин
max@evilmartians.com
http://evilmartians.ru/

2. :Задача
оптимизация
приложения
вконтакте
оптимизация
приложения

3. • 30 тыс пользователей
• 9до секунд на запрос
• 5 серверов
• 500надо опустить время ответа домс
Вводные

4. • 2-Более х млн пользователей
• 25 мс на запрос
• 14 серверов
• 40K RPM 20и млн записей в сутки
Результаты

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 быстр и удобен
• — IOИндексы основной дисковый
SQL база

18. • —Много данных рядом плохо
• Нам повезло с логикой выборок
• : user_id % 100Шардинг
• Надо планировать заранее
Шардинг

19. • Меньше всего проблем
• Zero-downtime deploy unicorn-с ом
• Плохая поддержка шардинга
• RabbitMQНеобходимость
Ruby on Rails

20. • Самая быстрая часть проекта
• Оказался индикатором состояния
• Мучительное восстановление
RabbitMQ

21. • Rails do scale
• —Масштабирование вопрос
предметной области
• -У вас всё будет по другому
Выводы