'

Rails Scale: 1000 запросов в секунду

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

Ежедневная смена требований Экспоненциальный рост нагрузки Поровну записи и чтения Сделать быстро, дешево и приемлемо С чем столкнулись


Слайд 5

Что оказалось важным в нашем случае


Слайд 6

Грамотный менеджер «Щасспрошу» завалит проект Персонал


Слайд 7

Системный администратор. Получше, чем «aptitude-джан» Персонал


Слайд 8

Наша команда злых марсиан! http://evilmartians.ru/ Персонал


Слайд 9

Волшебных гномиков нет.


Слайд 10

Нет их даже в MongoDB и memcached


Слайд 11

pgpool — master-master медленный memcached — нечего кешировать Сразу выкинули


Слайд 12

Ruby on Rails — нужна гибкость PostgreSQL — часто меняется схема RabbitMQ — задержка записи внешний инструментарий Оставили


Слайд 13

Что мы делали


Слайд 14

Без него никуда Догадки не работают newrelic.com Фоновые задачи очень важны Профилирование


Слайд 15

Место на дисках Упавшие серверы Длины очередей Ночной дежурный (?) Мониторинг


Слайд 16

Нужны реляционные выборки Часто меняются критерии PostgreSQL быстр и удобен Индексы — основной дисковый IO SQL база


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


×

HTML:





Ссылка: