Как создавался Project1917 и как мы выдерживаем 1000 RPS на...
-
Upload
itsumma -
Category
Technology
-
view
87 -
download
1
Transcript of Как создавался Project1917 и как мы выдерживаем 1000 RPS на...
Как создавался Project1917 и как мы
выдерживаем 1000 RPS на одном
сервере
Спорышев Сергей. ITSumma
Спорышев Сергей
Содержание
1. О проекте
2. Организация работы. Команда
3. Стек используемых технологий
4. База данных. Отношения между моделями
Содержание
5. Администраторская / редакторская часть
6. Публичная часть
7. «Впрод»
8. Что из этого получилось и как жить дальше?
О проекте
« … лучшая социальная сеть в истории:
все пользователи давно умерли … »
О проекте
‣ Познавательный проект, выполненный в формате социальной сети,
где активными пользователями являются реальные исторические
личности жившие в 1917 году
‣ Все посты основаны на реальных документах, письмах,
публицистических материалах
‣ Пользователи «нашего времени» имеют возможность
комментировать, «лайкать» и делиться материалами в других
социальных сетях
Организация работы. Команда
Организация работы. Команда
‣ Конкретные день и время релиза, 0 % вероятности изменения срока
‣ Команда: менеджер проекта, 3 разработчика, 2 системных
администратора, 2 тестировщика
‣ Методология Scrum
Организация работы. Команда
‣ Общение с заказчиком – только ПМ и ведущий разработчик
‣ Feature Branch
‣ No Rocket Science
Стек используемых технологий
Стек используемых технологий
‣ PHP 7 + Nginx + Mysql
‣ Memcached, ffmpeg, image
magic
‣ Angular JS 1.5.8
‣ Gulp (Laravel elixir)
База данных.
Отношения между моделями
База данных.
Отношения между моделями
‣ No morph-by-many, has-many-through
‣ Некоторые отношения many-to-many – отдельная модель
‣ Методы-мутаторы
База данных.
Отношения между моделями
‣ Транзакции, «мягкое удаление»
‣ Индексы
‣ Кэширование
Администраторская / редакторская
часть
Администраторская часть
‣ Пакет Repository, RESTFful API
‣ События (сброс/перегенерация кэша, синхронизация отношений)
‣ Очереди
‣ Постобработка входных данных
Администраторская часть
‣ JS-навигация
‣ Resource, repository & cache
‣ Разделение на компоненты
Администраторская часть
‣ Максимально быстрая работа
‣ Функциональность важнее внешнего вида
‣ Создание нового раздела – не больше дня
‣ Создание нового компонента – не больше часа
Публичная часть
Публичная часть
‣ Поиск, фильтрация данных – репозитории
‣ Использование сервисов для определенных блоков сайта
‣ Singleton-объекты
‣ Минимизация пользовательского ввода
Публичная часть
‣ Структурирование view-компонентов для многоразового
использования
‣ Всю статичную информацию выводим сразу
‣ API для уникальной и динамической информации
Публичная часть
‣ БЭМ
‣ Минимизация и оптимизация angular, bindonce
‣ Динамическая подгрузка – html
‣ Localstorage, cookies
Публичная часть
‣ Минификация и обфускация css/js
‣ Оптимизация и ресайзинг изображений средствами nginx
‣ Раздача статики с помощью CDN
ВПРОД
ВПРОД
‣ Кэширование на уровне nginx + «белый список» url’ов
‣ Резервное копирование
‣ Мониторинг важных показателей, алерты
ВПРОД
‣ Нагрузочное тестирование – 700-900 RPS с выключенным кэшем,
1200-1400 RPS с включенным кэшем
‣ Резервный сервер – минимизация времени переключения
‣ Uptime – 99.93%
Что из этого получилось и как жить
дальше?
Что из этого получилось и
как жить дальше?
‣ Предугадываем «хочу» и «хочу потом» клиента
‣ Яндекс Облако – плохо
‣ Последняя неделя – экстрим разработка 24/7
Что из этого получилось и
как жить дальше?
‣ Первая неделя – стабильно 400 RPS
‣ Мощный социальный отклик
‣ Множество новых готовых компонентов
Что из этого получилось и
как жить дальше?
‣ Англоязычная версия сайта
‣ В случае роста нагрузки – апгрейд сервера (8 ядер – 24 ядра)
‣ При продолжении роста нагрузки – горизонтальное
масштабирование
Спорышев Сергей