Комментарии 12
200 RPS для mysql на сервере с CPU 96 ядер? почему так сильно был нагружен сервер? на типичные запросы смотрели? модет надо было индексов добавить? или нагрузка шла во время создания сводных отчетов? тогда вроде как решается репликой на которой и запускают тяжелые запросы
Нагрузочное тестирование показало предельное RPS 200 (Requests Per Second – количество запросов за одну секунду).
200 RPS – это показатели группы back-end серверов.
В свою очередь, нагрузка на сервер базы данных достигала порядка 40тыс. RPS, при которой распределение запросов чтение/запись = 50/50.
MySQL является не самым практичным решением при растущем количестве операций записи.
А что это было конкретно?
Что за монстр с 96 CPU и 192 ОЗУ держит всего 200 RPS на обьеме в 500 Гб? Зачем это вообще? Засуньте все в память и будет вам скорость, если уж так надо. Может 200 тыс rps?
Аналогично с балансировщиками. 24 отдельных сервера для липких сессий? Чем не устроил один? Nginx на VPS за тысячу в месяц сбалансирует 200 rps и не чихнет даже.
Как я понимаю, товарищи из статьи не трогали код Moodle, а лишь работали на уровне администратора, то есть настраивали Линукс и правили конфиги. Оптимизировать наверняка можно, но надо подключать программистов.
Насчет количества транзакций возникло заблуждение, которое подробно разъяснили в комментарии выше.
Говоря про 24 сервера балансировщика – важно уточнить, что в контексте статьи подразумевалось 24 малоядерных сервера бекенда системы Moodle, распределение трафика на которые уже осуществляет L7-балансировщик (один сервер в регионе).
Согласен с предыдущими комментаторами - странные решения.
Плюс - я не согласен что переход от архитектуры "с разными базами данных в разных дата-центрах, где каждый сервер находился в регионе присутствия компании" к центральной базе оправдан.
Основопологающим требованием было осуществление строгой консистентности данных при сдаче тестирования, а также централизация данных для генерации сводных отчетов.
В случае регионального распределения – пришлось бы сводить базы в одну, решать проблемы с пересечением идентификаторов.
Также нам было поставлено техническое ограничение – совместимость интерфейса СУБД с интерфесом MySQL, что не позволило нам использовать СУБД с поддержкой регионального масштабирования операций записи.
Совсем не понятно, почему пиковые нагрузки всего в 12 тысяч пользователей требуют таких ресурсов.
Всегда был уверен, что при таких неравномерных нагрузках как раз стараются увеличить и/или сделать динамически изменяемым количество серверов, а не сводить все в один, пусть и "надежный кластер из одной ноды от Яндекса".
Картинка "Сэкономленные деньги - это заработанные деньги" глаза режет - СтоИмость, платфоРмы
Задачу люди решили. Две организации не смогли сделать. Значит задача была не из простых. Красавчики.
Спасти за 60 дней: новая архитектура для ресурса с большой нагрузкой