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

Что можно сказать?
Это успех

Первый снимок тот, который без надписей.
Второй - про update

Количество запросов меньше в 2 раза.
Количество соединений с БД и процессов меньше примерно в 1,5 раза.
Объем трафика в пике сокращен в 2 раза.
Процессор "расслабился"), загрузка уменьшена в 2 раза.

По ощущениям скорость выросла раз 5, как минимум. Потому что теперь не только нет потерь на обращении к MySQL, но и PHP уже не работает, посмотрел, что в кэше лежит готовый HTML.

Супер! Надо будет продолжить
Еще чего-нибудь закэшировать ))
Еще чуть-чуть и точно на такой скромной конфигурации сервера 50 человек смогут одновременно жить

Посмотрел кэш. Такие "маленькие" snippets, а такие "вредные" столько ресурсов кушали...

Спасибо.

Количество SELECTов резко сокращено. Раньше почти весь пирог были SELECTы.
Теперь вопрос, нужно ли так часто выполнять SET OPTION? Они теперь лидируют.
Хотя, может быть это PHP MyAdmin часто их выполняет. Не смогу сейчас сказать.

Сущность "Запросы клиентов" сейчас содержит у нас уже 81 поле. В итоге их точно будет около 100. Из них
- поля для текста: 7
- формулы: 15

Другие основные сущности тоже содержат уже под 50 полей и около десятка формул.

Соответственно, если мы выполняем SELECT * всякий раз, то мы тянем много текста и + более 50 полей, которые не нужны.
Также, если в этом случае происходит вычисление всех формул, то это тоже не нужно, т.к. например, нужно вывести таблицу с запросами, в которых показаны только названия запросов, кому назначены, даты, элементы списков и статусы. Список может быть длинным. Однозначно более 100 записей. Такие списки открывают все пользователи. Соответственно на 10 пользователей объем неиспользуемых данных, которые отправит MySQL будет уже ощутимо велик.

Нужно реализовать запросы в отчетах так, чтобы в SELECT запрашивать только нужный набор полей.
В целом SELECT * можно применять только для внутренних служебных таблиц. Например, для app_entities, app_configuation, app_reports.

А когда обращаемся к app_entity_NN, то после SELECT указываем только тот список полей, которые нужны для отображения в отчете, который будет построен.

Для просмотра отдельной сущности, скорее всего можно оставить SELECT *.

Также, как кэшировали отчеты, можно кэшировать основное меню. Руководитель тоже каждый раз обращается к БД, чтобы его построить. Тоже даст прирост производительности и сократит нагрузку на базу.

Когда мы ориентируемся на серьезные решения, то для количества одновременных пользователей порядка 100, каждая такая мелочь дает реально ощутимый прирост производительности.

Соответственно, если мы выполняем SELECT * всякий раз, то мы тянем много текста и + более 50 полей, которые не нужны.

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

Также, как кэшировали отчеты, можно кэшировать основное меню. Руководитель тоже каждый раз обращается к БД, чтобы его построить. Тоже даст прирост производительности и сократит нагрузку на базу.

В принципе можно, но тут дело осложняется тем, что кеш должен каждый раз обновляться при настройке сущностей, отчетов, настройке прав и т.д. Все эти вещи сложно предусмотреть. Несколько простых запросов не повлияет на производительность. Вот мы с вами в 10 раз сократили простые запросы и что? Явных улучшений это не дало, потому что основная нагрузка идет на формульные поля, тоесть сложные вычисления с под-запросами.

По поводу SET OPTION, Руководитель постоянно выполняет команду "SET sql_mode" но это не всегда нужно, и я вынес настройку в config.php
Так же SHOW PRIVILEGES нужно проверять только при работе с сущностями, так же поправил этот момент.

support писал(а): 15 янв 2018, 20:13

Соответственно, если мы выполняем SELECT * всякий раз, то мы тянем много текста и + более 50 полей, которые не нужны.

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

Согласен, Вы правы, что сложно предусмотреть. Наверное эту доработку пока стоит отложить. Надо обдумать, какой способ будет лучше. Здесь явно есть несколько способов решения. Тоже буду думать, как что-нибудь надумаю, напишу.

в config/server.php
по подобию с другими путями надо добавить путь к /cache
define('DIR_FS_CACHE....);

ага, добавлю.

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

Условий вроде как не много и мы должны делать вычисления:
1) Если используется фильтр по полю формула
2) Если поле в списке
3) Если в списке поле "Текст по шаблону" в котором есть формула

Вроде все учел. Во всех остальных случаях, формульные запросы не будут добавляться в запрос.

В архиве доработка. Это уже обновление на бета 3.

После применения, проверяем расчеты формул именно в списке.

Интересно, уменьшится ли нагрузка на сервер после данных изменений. Должна.