CRM Руководитель - Форум

Нужно продолжать работу по оптимизации запросов.
Работает всего лишь 7 пользователей, и они создают 10 000 запросов к БД в секунду.

Я обратил внимание, что Руководитель везде в запросах к MySQL запрашивает полный набор полей записей - SELECT *.
У меня сущность "Запросы клиента" содержит уже больше 50 полей. Другие сущности от 10 до 30 полей.
Сейчас MySQL на каждый запрос, чтобы получить 1 поле отправляет все поля и это создает просто "бешенную" нагрузку.
И таких запросов получается в секунду тысячи.

Прошлым запросом мы сократили количество дублированных запросов.
Этим запросом надо начать работать над их "чистотой".

1. Нужно сделать, это исправить, что там, где нам надо получить 1-2 поля из записи, в этом месте на надо делать запрос к БД на получение всех записей SELECT *
2. Если формула не используется (а формул у меня уже больше 50 и будет, предполагаю в итоге больше 200), то не надо ее запрашивать. Такое количество формул у нас будет использовано в разных отчетах. Но если на каждый отчет мы делаем запрос SELECT * и с формулами MySQL, то задержки будут большие.

Потом следующим этапом можно будет заняться индексами.

Это нужно сделать, чтобы приблизить систему к тому, что заявлено:

Пользуясь множеством настроек, за полчаса вы сможете развернуть на своем сервере систему управления проектами, персоналом или другую (CRM, ERP, HRM, WMS и т.д.).

На самом деле за полчаса не развернуть, лукавство но вообще можно за большее время. Только надо с БД разобраться

Сходил к нашему системному администратору. Грустная ситуация.
У нас система виртуальных машин настроена так, что если есть свободный ресурс, то наиболее активная виртуалка может его занять. Так наша виртуальная машина с Руководителем сейчас "ест" весь сервер. Далеко за 2 выделенных ядра процессора. 2 ядра процессора ей гарантировано, но поскольку, сейчас другие пользователи сервера не так активны, как мы, то мы захватили и другие ядра. И все равно не хватает и тормозит.

Поэтому проблему надо решать.
Считайте, что Вы получили нагрузочное тестирование Руководителя на реальном проекте, где задействован все его возможности (формулы, автостатусы и т.д.). Реально планировалось посадить на него до 50 одновременных пользователей, но если мы не оптимизируем работу с БД, то даже 5 человек не смогут комфортно работать.

У меня есть ряд гипотез, откуда такая нагрузка.
Позже напишу.

Добавил в план на 2.1. Я конечно подумаю что можно сделать, но в целом данная ситуация - это недостаток универсальности.
Дело в том, что вы можете использовать в качестве заголовка тип поля "Текст по шаблону" в котором будет тип поля "формула" + функции и приехали. В таком случае нам везде надо будет и поля и формулы. А вычислять где такое поле есть, а где нет, и плюс еще какие поля там нужны, то это еще + несколько запросов.

Но, как я уже сказал, я еще раз проанализирую запросы и в 2.1 мы вернемся к этому вопросу, но сокращать в больших объемах уже реально нечего.

И еще, от первоначального варианта мы сократили количество запросов в 10 раз, разве это не повлияло на производительность? Ищите проблему в другом месте.

Как я писал ранее, попробуйте обновиться до php 7 + MariaDB

Как я писал ранее, попробуйте обновиться до php 7 + MariaDB

На 10 000 запросах в секунду с объемом трафика от БД 40МБ/секунду очевидно, что результат будет тот же. В лучшем случае система начнет заваливаться не на 5, а на 10 пользователях.

Дело в том, что вы можете использовать в качестве заголовка тип поля "Текст по шаблону" в котором будет тип поля "формула" + функции и приехали.

Нигде такое не использую. Максимум: соединение ID + текста, формул и функций в Наименованиях нет.

Но, как я уже сказал, я еще раз проанализирую запросы и в 2.1 мы вернемся к этому вопросу, но сокращать в больших объемах уже реально нечего.

Мы сократили дублирующие запросы. Сейчас речь идет не о повторных одинаковых запросах, а об их структуре.
О самом содержании каждого SQL-запроса.

И еще, от первоначального варианта мы сократили количество запросов в 10 раз, разве это не повлияло на производительность? Ищите проблему в другом месте.

После последней оптимизации она ухудшилась. Систему я не менял к тому времени еще. Все было по прежнему.

Проблема, как уже обозначил, в "архитектуре SQL-запросов".

Позже вышлю обновленную конфигурацию, скриншоты разделов отчетов и логи запросов, которые генерирует Руководитель с предложениями по оптимизации.

Если посмотреть со стороны, основную проблему создают отчеты в верхнем меню, ведь они обновляются при каждой перезагрузке странице, чтобы пользователь не делал, и из за этого каждый раз отправляется такая куча запросов.

Давайте попробуем их закешировать. Вы как админ, сможете включить кеш и настроит время жизни кеша. Естественно кеш не будет применяться для отчетов с опцией "Автообновление". Это должно решить проблему с большим количеством запросов, отправляемых одновременно.

Пробуем?

Да. Классная идея!

И, кстати, нашел формулу, которая "клала" сервер. Убрал, процессор ожил.
Но все мои предложения все равно актуальны

Потом проанализирую, как она так работал, что "клала сервер".

Сохраню пока сюда картинку. После изменения с кэшированием отчетов из верхнего меню сравним новую картинку с этой.

Готово! В меню появится пунтк Настройки -> Нагрузка на сервер
Опция "Использовать кэш" по умолчанию отключена. Включаем. Время жизни кэша по умолчанию 5 минут.
Кеш хранится в папке "cache/"

Показывайте скриншоты для сравнения.