Добрый день, Дмитрий.
Из всего, что делает программа, самой длительной операцией является работа с данными в базе. Т.е. самой важной частью сервера является место размещения базы данных. Так как в качестве сервера используется десктопный компьютер, то желательно, чтобы в нём стоял SSD диск., а не HDD. В качестве информации можно поискать в Интернете сравнительные характеристики работы на SSD и HDD.
Второй важный момент сетевой работы - пропускная способность в локальной сети. Если структура проекта достаточно сложная, то клиентская часть выполняет несколько запросов на сервер за получением данных из базы. Если сетевое соединение достаточно слабое, то будут наблюдаться серьёзные задержки в работе. Но как показывает практика - тут, в отличии от замены HDD на SSD, улучшить работу не всегда возможно.
Все остальные действия выполняются несравнимо быстрее и не оказывают столь существенного влияния на быстродействие. Но всё-таки желательно ставить более мощный процессор и бОльший объём памяти (с более высокой скоростью работы).
Некоторые пользователи конструктора изначально использовали старые компьютеры в качестве сервера, или того хуже - серверная часть устанавливалась на пользовательский компьютер, где человек не только работал, но и играл. Перенос менеджера сетевых проектов давал заметное улучшение в работе для подключающихся пользователей.
Если ведётся работа через Интернет, то все вышеприведённые рекомендации практически не помогают, так как в этом случае передача данных становится очень долгой и совсем не конкурирует с работой железа.
В этом случае помогает только грамотное построение структуры проекта, а также задать специальные параметры при сетевой работе.
На странице справки
http://runabase.ru/help/useful.html#network даны общие рекомендации по оптимизации работы. Распишу подробнее, для чего что нужно.
-
снизить число записей На странице, отображаемых в списке (в свойствах проекта): даёт самый значительный выигрыш в работе, так как заполнение таблицы с данными в объекте или форме - одна из самых ресурсоёмких операций в программе. Обычно менеджер вычитывает всю таблицу в базе данных, после чего производит отбор необходимых записей. Сколько бы записей ни было в объекте, все они будут зачитаны, затем будут произведены операции сортировки и фильтрации, а затем будет отобрано необходимое число для передачи клиенту. Уменьшение пейджинга (желательно до 100-200 записей) просто обязательно при работе через Интернет.
-
в менеджере свойство для проекта "Реакция на изменение" установить в значение "автоматическое обновление" (при 5-10 пользователях) или "ручное обновление" (от 10 и более пользователей): данная настройка была в 5-ой версии. В 6-ой версии она убрана и вместо неё работает только последний вариант, когда пользователю под списком показываются кнопки обновления списка и просмотра произведённых действий другими пользователями с момента последнего обновления данных на этом компьютере.
-
минимизировать число отображаемых полей в списке (в объектах и в формах): при чтении данных из базы данных производится получение только тех полей, которые отображаются в списке. Каждая лишняя колонка повышает "вес" передаваемого пакета данных и замедляет её скорость. Чем меньше видимых граф в таблице - тем быстрее будет её заполнение. Некоторым пользователям программы нравится включать в отображение таблицы максимальное число полей. Даже при индивидуальной работе с базой - это существенно замедляет работу. Мы считаем это моветоном в программировании проекта.
-
минимизировать число дочерних списков и отображаемых в них полей: всё вышеописанное для родительской формы относится и к дочерним спискам. Открытие формы с одним дочерним списком замедляет передачу данных в два раза, с двумя - в три раза, и т.д. Понятно, что от дочерних списков избавиться нельзя, но озаботиться их оптимизацией также желательно. В будущем будет добавлен специальный инструмент перехода по формам, который позволит открывать данные одного объекта в разных формах, быстро переходя по кнопке в контекстном меню списка.
-
в списке записей (объектов/форм) минимизировать число полей ссылок на объекты: каждое поле ссылки на объект - это дополнительный запрос в БД за ключевым полем. С 5-ой версии так и работало: было 3 ссылки на поля - было 3 доп. запроса в базу, 10 ссылок на объекты - 10 доп. запросов в базу. Т.е при просмотре/редактировании записи, время её открытия увеличивалась в разы. В 6-ой версии для полей ссылок на объекты, по возможности, запрос группируется в один (но это удаётся не всегда).
-
убрать для строковых полей свойство Автоподбор: данное свойство требуется при создании/изменении записи. Если это свойство установлено, то при получении данных из базы, программа также запрашивает и все данные для выпадающего списка, из которого будет производиться автоподбор данных. Можно проверить - действительно ли это помогает, отключив автоподбор и проверив работу по сети. Будет полезно, только если данных в объекте списка более тысячи.
-
минимизировать количество итоговых полей в форме итогов: каждое итоговое поле - это запрос в базу, который подымает все записи, производит расчёт и возвращает одно значение. В первую очередь - это большая нагрузка на сервер.
-
выполнить операцию оптимизации базы данных: при оптимизации производится физическая очистка удаленных записей из файла БД, а также устанавливается индексация для таблиц. Получение данных из индексированных таблиц может быть на порядки быстрее (в одном из тестов неоптимизированный объект с несколькими миллионами записей открывался около 1 минуты, а оптимизированный - 1,5 секунды).
И напоследок ещё добавлю: мы постоянно перерабатываем программу, стараясь оптимизировать её работу, особенно по сети. Зачастую на это уходит очень много времени, но мы считаем это абсолютной необходимостью для конструктора. Особенно с учётом того, что сам конструктор постоянно усложняется и "утяжеляется" его работа. Новый внешний вид программы значительно замедлил скорость вывода данных на экран (управление полями производится на уровне программы, а не платформы Qt; везде присутствуют скроллинги; включаются/выключаются/блокируются поля через группы, подкраска полей при помощи групп, и пр.), поэтому мы постоянно ищем способы оптимизации внутренней работы Руны.
