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

Презентация:



Advertisements
Похожие презентации
Использование MySQL в сервисе дневников LiveInternet.ru Практика, практика, практика Гурьянов Андрей, программист Новиков Лев, системный администратор.
Advertisements

Антикризисная презентация Александр Тищенко, Evil Martians Railsclub 4 октября 2009 года.
Делаем дешевый видео- хостинг в условиях кризиса Сергей Нековаль Денис Елданди «Грамант»
Erlang: сырая игрушка или надежный инструмент? Макс Лапшин, «Злые марсиане»
Реализация элементов логики приложения в MySQL: триггеры, хранимые процедуры, кэширование Сергей Горшков, технический директор Центра информационных технологий.
Как Map/Reduce спас Яндекс.Статистику. Background Взрывной рост объема данных, за 8 лет объем дневных данных вырос в 2000 раз с 2ГБ до 4ТБ Скорости процессоров,
Платформа разработки высоконагруженного веб-сервиса: инструменты отладки и возможности масштабирования Александр Демидов руководитель направления арендных.
BigData изнутри: технологии и алгоритмы Александр Сербул руководитель направления, разработчик Партнерская конференция «1С-Битрикс»
Архитектура новой почты Рамблера Андрей Шетухин. Rambler Mail сегодня 240 тысяч новых регистраций в день 66 миллионов пользователей 20 миллионов живых.
SQL SERVER И ПРОДУКТЫ 1С 1. 1С + Microsoft = ПАРТНЕРСТВО 2 Сотрудничество 15+ лет Совместный продукт с 1998 года + Гибкость лицензирования Отдельная закупка.
Профилирование Эрливидео Макс Лапшин
Большой Drupal Клера Виленская. Производительность на одном сервере 99 пользователей: 80% аутентифицированных 30% добавляют контент зарегистрировано 1000.
Пошаговый алгоритм разработки высоконагруженной системы Олег Бунин
Лекция 4 Управление задачами Диспетчеризация. Трехуровневое планирование Планировщик памяти 1.Сколько времени прошло с тех пор, как процесс был выгружен.
I T M S Время – деньги. Бенджамин Франклин «Совет молодому купцу» 1748.
Распределенная Архитектура LAMP приложений Петр Зайцев Директор, Percona Ltd.
Правильная архитектура высоконагруженных решений в Windows Azure Дмитрий Мартынов microsoft.com.
Масштабируемая система голосования на базе PostgreSQL PgQ Сергей Нековаль «Грамант»
Jalapeño – эффективная разработка приложений для Java Морозов Максим InterSystems Symposium 2007, Москва 4-5 сентября.
Нагрузочное тестирование как способ снижения рисков Олег Бунин.
Транксрипт:

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

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

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

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

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

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

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

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

Наша команда злых марсиан! Персонал

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

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

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

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

Что мы делали

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

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

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

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

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

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

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