В промежутке между приемом и визуализацией данных ThingWorx Platform также требуются достаточные системные ресурсы для выполнения любой бизнес-логики и преобразования данных приложения.

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

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

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

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

Передача файлов на устройства Edge и с них является общим требованием для вариантов использования приложений ThingWorx.

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

При развертывании в конфигурации с высокой доступностью (как описано в разделе ThingWorx высокой доступности) часто используется конфигурация реляционной базы данных с высокой доступностью.

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

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

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

Аналогично сторонние инструменты (такие как SCADA, ERP или другие интегрированные офисные приложения) могут также использовать соединения WebSocket с платформой.

Если эти инструменты получают доступ к ThingWorx с помощью вызовов REST API, это увеличивает число HTTP-запросов в секунду, рассчитанное ранее для визуализации данных.

Для каждого соединения WebSocket требуется память на платформе, поэтому рекомендуется увеличить суммарное выделение памяти для платформы (или размер/класс выбранной виртуальной машины), если ожидается много параллельных сессий туннелирования или запросов REST API.

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

Объем исторических данных, сохраняемых на платформе, влияет на размеры базы данных и системы платформы. Для более крупных источников данных (потоки, таблицы данных и потоки значений) потребуется больше транзакций для запроса из базы данных. Эти длинные транзакции могут также привести к резервному копированию очередей потоков и потоков значений и использовать дополнительную память.

Настоятельно рекомендуется накапливать данные таким образом, чтобы ни один источник не содержал слишком много записей (подробности см. в этом руководстве по оптимальным методам (на английском языке)). Если требуется большой объем исторических данных или требуется хранить большие объемы принятых данных долгое время, подумайте о более надежном решении базы данных. См. ниже сведения о следующих опциях базы данных: