Тестирование производительности в Mirth Connect с использованием JMeter

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

По нескольким причинам старайтесь не тратить слишком много времени на «тестирование всей системы»:

• Во-первых, тестирование всей системы обязательно включает тестирование низкоуровневой конфигурации, такой как количество ядер ЦП, сетевые карты, используемые в коробке, и программное обеспечение уровня ядра, такое как стек TCP/IP. Обычно у вас нет никакого контроля над этими вещами, поэтому вы не можете их оптимизировать.
• Во-вторых, производительность всей системы будет сильно зависеть от того, какой вспомогательный код будет выполняться в системе. Если системный администратор решит «улучшить» мой процесс Mirth или использовать этот ящик для размещения SQL-сервера, это повлияет на систему, которую я (опять же) не могу контролировать.
• В-третьих, и, если честно, я считаю, что «производительность всей системы» — это то, о чем руководство спрашивает во время настройки системы, чтобы они могли получить оценку затрат; но они знают, что получают только оценку. Вы делаете все возможное, чтобы использовать тестовые метрики, чтобы получить хорошее предположение для первоначального выделения оборудования, но все знают, что на самом деле именно производственные показатели производительности будут определять последующие затраты на выделение ресурсов.

Убедитесь, что вы создаете свои каналы для тестирования. Я считаю, что гораздо проще тестировать канал, когда источник и место назначения можно изменить на «Channel Reader» и «Channel Writer» без изменения обработки сообщений. Один из способов взглянуть на это заключается в том, что вы не собираетесь переделывать стек MLLP в Mirth или стек TCP в Java, поэтому просто исключите эти вещи из своего тестирования.

Я храню источник полезных тестовых сообщений. У меня есть пара файлов на сетевом диске, содержащих около сотни сообщений, проверяющих неприятные пограничные случаи, с которыми я сталкивался на протяжении многих лет на своих интерфейсах HL7. Я написал небольшой канал Mirth, который считывает их из файла и выдает копии так быстро, как только может. Включив «Очередь» на стороне назначения этого канала, я могу поставить в очередь огромное количество тестовых сообщений, которые готовы отправить на канал, который я хочу протестировать. В прошлом я тратил время на создание тестового интерфейса, который действовал как фальшивый EMR, чтобы выдавать случайно созданные сообщения, но, похоже, не было никакого преимущества перед простым выбрасыванием копий тех же сообщений из моих тестовых файлов.

Наконец, и это наиболее важно, очень важно измерять производительность тестового экземпляра с помощью тех же показателей, которые вы будете использовать для измерения производительности рабочего экземпляра. Если единственная производственная метрика, о которой вы заботитесь, — это «сообщений в секунду», то это то, что вам нужно измерить на тестовом блоке. Если объем памяти вызывает беспокойство в производственной среде, вам также необходимо измерить использование памяти в тестовой среде. Когда вы вносите изменения в свой тестовый экземпляр, которые уменьшают важную метрику на 10 %, вам нужно убедиться, что ваше руководство знает об этом, прежде чем внедрять это изменение в рабочую среду.

Обратите внимание, что получить некоторые из этих показателей может быть сложно, поскольку Mirth не включает в себя хороших инструментов для мониторинга собственной производительности. Приборная панель Mirth — это хорошее место, чтобы следить за ошибками или сбоями, но это не лучшее место для поиска данных о производительности. Во время тестирования я удостоверяюсь, что использую любой инструмент мониторинга ресурсов, который системные администраторы будут использовать для мониторинга производительности рабочего экземпляра. Кроме того, я использую ручной процесс для проверки производительности: если я хочу подсчитать количество сообщений в секунду, я отправляю пакет сообщений и смотрю временные метки первого и последнего сообщений. Если я хочу получить представление о загрузке ЦП канала Mirth, я использую монитор производительности Windows или команду posix 'top'.