БД: Оптимизация запросов

[nikolay.rastegaev]

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

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

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

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

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

[nikolay.rastegaev]

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

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

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

[nikolay.rastegaev]

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

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

[nikolay.rastegaev]

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

[support]

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

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

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

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

[nikolay.rastegaev]

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

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

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

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

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

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

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

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

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

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

[support]

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

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

Пробуем?

[nikolay.rastegaev]

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

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

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

[nikolay.rastegaev]

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

[support]

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

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