Как создавался 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 ядра)

‣ При продолжении роста нагрузки – горизонтальное

масштабирование

Спорышев Сергей