Производительность привязок

Привязки моделей и виджетов обрабатываются пулами потоков, работающих параллельно. Иногда пул (имеющий определенные пользователем настройки) недостаточно большой, и скорость получения обрабатываемых запросов новой управляемой событиями привязки или периодической привязки выше чем скорость обработки.

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

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

Выполнение периодических привязок

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

Преимущества привязок при событии над периодическими привязками:

  • Меньшая загрузка ЦП, меньшее использование ввода/вывода диска и сети, так как вычисления выполняются при фактических изменениях значения.
  • Незамедлительная реакция на изменения значений. Периодические привязки отражают лишь изменения в конце периода. Уменьшение периода оценки ведет к более высокому потреблению ресурсов.

Распараллеливание привязок

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

Пул конфигурируется тремя настройками:

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

Другими словами, пул работает следующим образом:

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

Учет количества потоков

Потоки, которые обрабатывают привязки, обычно достаточно энергозатратные, чтобы создавать и поддерживать их относительно ресурсов системы. Каждый поток получает от RAM от 128 до 512 килобайт для внутреннего стека и потребляет определенное количество ресурсов CPU для переключения контекста, то есть ядра CPU переключения между разными потоками.

Поэтому обычно количество потоков необходмо удерживать на низком уровне. Практический максимум потоков для современных приборов на серверном уровне около 10-20 тысяч, для автоматизированных приборов это 5-10 тысяч. Однако полное количество потоков в высоко загруженном SberMobile Server должно быть ниже 1000-1500, количество потоков в SberMobile IIoT Platform Client, который запускает множество виджетов, должно быть ниже 300-500.