Стоит ли беспокоиться о масштабировании на этапе разработки?

Question

[Алексей Максимов]

Частенько задумываясь о будущих нагрузках, меня посещает мысль о масштабировании моего проекта. Я использую WebSocket серверы на PHP как демоны (научил их общаться между собой через Memcache), Memcache и MySQL, а так же сессии на файлах.

Что из этого набора может вызвать в дальнейшем трудности при горизонтальном масштабировании и стоит ли мне что-то менять?

Answer 1

[Сергей Протько]

redis, у него есть pub/sub интерфейс так что можно заставить общаться демоны через него, можно хранить в нем сессии...

Частенько задумываясь о будущих нагрузках

Тогда вы должны писать нагрузочные тесты, а не филосовствовать о том что можно еще сделать просто-так. В целом если вы не занимались настройкой ядра у вас начнутся проблемы уже на 1000-е активных пользователей (по умолчанию PHP не умеет в stream_select обрабатывать более ~1024 файловых дескриптеров, а операционная система и вовсе по умолчанию ограничивает количество всех файловых дескрипторов на процесс.

Горизонтальное масштабирование web socket серверов нужно когда у нас количество активных пользователей которые одновременно пользуются системой доходит ближе к 10К а то и больше (нагрузочные тесты все покажут).

То чем вы занимаетесь называется преждевременной оптимизацией.

Answer 2

[Назар Мокринский]

Как минимум сессии на файлах не очень мягко говоря масштабируются. Так же непонятно как WebSockets сервера общаются через Memcached, было бы логичнее тот же WebSockets использовать для их общения между собой.
Просто разделите всё на отдельные серверы и продублируйте. Всё ещё работает вместе как надо? Значит масштабируется.

Comments

[Алексей Максимов]

Ни один проект не будет работать "вместе как надо", если его просто разделить на 2 сервера без какой-либо связи.

[Алексей Максимов]

А по поводу memcache и WebSocket - я храню данные о подключённых клиентах в memcache, а каждый из WebSocket получает оттуда данные или записывает, если нужно.

[Назар Мокринский]

Алексей Максимов: Вот и я о том. Если вы хотите масштабирование - все компоненты изначально должны быть готовы к тому что их просто разделят - и это ничего не сломает. К примеру, у меня сейчас сайты - это набор Docker контейнеров. Сами контейнеры из коробки поддерживают масштабируемость, то есть одна нода MariaDB уже не просто одиночный сервер, а кластер из одной ноды. Как только я пишу docker-compose scale mariadb=5 - у меня поднимается ещё 4 ноды, которые автоматически подключаются к кластеру и реплицируются, а в это время балансировщик нагрузки сам переконфигурируется и распределяет запросы на уже 5 нод, а не на одну. Репликация Master-Master. То есть добавление серверов MariaDB не требует никаких ручных манипуляций, всё автоматизировано.

[Алексей Максимов]

Назар Мокринский: я не занимаюсь масштабированием, я лишь не хочу, чтобы потом не пришлось кому-то переделывать весь проект для этого.

[Назар Мокринский]

WebSockets штука асинхронная, что значит "получает"? У меня, к примеру, между серверами отделные WebSockets соединения с автоматическим выбором мастера. Таким образом люди подключённые к разным серверам могут в реальном времени общаться в одном чате.

[Назар Мокринский]

Тогда думайте наперед об упомянутых мной нюансах. А вообще если станет вопрос масштабируемости - то вполне вероятно что переписывания не избежать.

[Алексей Максимов]

Назар Мокринский: WebSocket сервер на PHP не асинхронный.

[Назар Мокринский]

Алексей Максимов: С чего бы это не асинхронный?)

[Алексей Максимов]

Назар Мокринский: потому что там обычный цикл, обрабатывающий все запросы.

[Назар Мокринский]

Алексей Максимов: Почитайте про event loop (возможно у вас примитивнейшая его реализация, но сути это не меняет). JavaScript в браузере работает точно так же. Полагаю, вы путаете асинхронность и многопоточность.