Павел Прищепа. Бббыстрый бэкенд на базе Друпал
DESCRIPTION
Выступления на DrupalCafe#7@Omsk от сибирского сообщества друпаллеров НП "ДрупалСиб". В случае использования традиционных подходов, скорость работы друпала в качестве бэкенда для single-page application или в качестве мобильного бэкенда - не выдерживает никакой критики. Конечно, всегда можно написать быстрый бэкенд на Node.js, Pytnon, использовать NoSQL базы данных. И все это будет работать достаточно шустро. Но это решает только часть проблем и порождает массу других: *найм новых специалистов, изучение новых языков программирования и фреймворков; *разнесение/дублирование бизнес-логики; *необходимость с нуля реализовывать многие вещи, которые давно есть в друпале; *... Для бизнеса это существенно повышает риски и стоимость проекта. Проект становится неуправляемым. Я расскажу: -как решить задачу создания быстрого бэкенда привычными средствами; -какие архитектурные решения надо использовать, чтобы иметь возможность масштабировать проект по мере его роста; -про паттерны построения высоконагруженных систем применимые к друпалу. ----- Сайт сибирского сообщества друпаллеров ДрупалСиб drupalsib.ru Группа сибирского сообщества друпаллеров Вконтакте vk.com/drupalsib Партнер Группа компаний И20 i20.bizTRANSCRIPT
БББыстрый бэкенд на Друпале
Да, ладно!
Павел Прищепа CEO DrupalJedi
Есть мнение, что Друпал не очень быстрый
• Громоздкий и неповоротливый
• Куча модулей, которые поднимаются каждый раз
• Он “ненавидит” БД
• Работает только с кешем
• Быстрые бэкендыПла
та за фун
кциональ
ность
и расшир
яемость
Я расскажу
• Как мы использовали Друпал
• Как мы отказались от Друпала как бэкенда
• Как открыли его с новой стороны :)
• И вернулись к Друпалу
Внутренний проект• SilkPaints - приложение для рисования
• Бэкенд на Друпале (Services)
• Юзеры рисуют, шарят рисунки
• Юзеров +400 000, изображений +500 000
• 5-20 запросов в секунду
• Процессор загружен на 40-70%
Запросы растут: запуск iOS версии
• Лайки
• Фолловеры
• Френдленты
• Забанить, удалить трек
• Списки: популярные рисунки, выбор редакции …
Планируемая нагрузка
• 5 000-10 000 новых пользователей ежедневно
• 50-100 запросов в секунду
• Время генерации ответа не более 0.4-0.8 секунды
• Размер БД (уже сейчас > 12 Гб)
Что делать,
шеф?
Ищем альтернативу Друпалу
• Node.js
• Python
• MongoDB
• Redis
Все не то :( Нельзя просто взять и начать
использовать новый фреймворк
• Изменение производственного процесса
• Обучение/найм людей
• “Набить шишки”
• Проект неуправляем
А время п
оджима
ет…
Бизнес т
ребует …
Back to Drupal• Redis
• Module EntityCache
• Module JS
• Module DrushD
• Drupal Queues API
Запрос
Worker
Worker
1. Минимальная обработка
2. Постановка Задачи в очередь
3. Быстрый ответ
Queue
Drupal
api.phpindex.php
Database (MySQL)
Worker 1 (DrushD)
Worker 2 (DrushD)
API Environment
Queue (Drupal based)
Ограничения API Environment
• Не использовать node_save() и node_load()
• Кастомный session.inc хендлер без user_load()
• Аккуратно подключать контрибные модули
• Использовать “легкие” таблицы и кэш
• Минимизировать JOINы в запросах
Queue
Внутренний сервис
Lock server (Redis)
Друпал модуль 1
Внешний сервис
Друпал модуль 2
Сервисн
о-ориенти
рованны
й
подход (SOA)
Лайки
Добавление рисунка в ленты
фолловеров
Пересчет статистики
Очереди с разными приоритетами
Результаты• В 10 раз снизилась нагрузка на БД
• Время отклика не более 1 секунды
• Загрузка процессора 10-30%
• “Простор” для масштабирования приложения
• SOA
Как еще ускорить?• Деградация функциональности
• Масштабирование
• Репликация
• Денормализация
• Асинхронная обработка
• Горизонтальный шардинг
• Выносить функционал в сервисы
На будущее• Основная причина тормозов - “кривые руки”
• Используйте то, что хорошо знаете
• Не более 1 новой технологии на проекте
• Оптимизировать только то что мешает “продавать”
• Помнить о “бизнесе”