Тестирование производительности просмотра Content Server (часть 3)

Это третья статья в моей серии, посвященной производительности просмотра Content Server.

В Часть 1 я исследую настройку и инструменты, которые буду использовать.

В Часть 2 я прохожусь по некоторым элементам инструментов, которые я использовал для регистрации времени производительности.

Итак, где мы находимся — тесты созданы, код запущен и успешно выполнен, так что давайте посмотрим. Ради скорости я буду смотреть на результаты испытаний от начала до конца. То есть общее время, затраченное на выполнение следующих тестов:

Тест 1

  • Перейдите к Enterprise Workspace (или /nodes/2000 в Smart UI)
  • Перейдите в папку Performance Test.
  • Перейдите к папке 50 Folders.

Тест 2

  • Перейдите к Enterprise Workspace (или /nodes/2000 в Smart UI).
  • Перейдите в папку Performance Test.
  • Перейдите к папке 100 элементов.

Результаты могут отличаться

Давайте проясним, что это не должно быть эмпирическим доказательством того, как работает Content Server — например, очень немногие люди будут развертывать один экземпляр с базой данных Postgres в рабочей среде. Я просто пытаюсь предложить что-то лучшее из слухов и предположений, когда дело доходит до сравнения производительности двух конкурирующих пользовательских интерфейсов в Content Server. Будут лучшие способы улучшить вашу производительность:

  • Добавление дополнительных ресурсов на уровне базы данных (IO, CPU)
  • Наймите администратора баз данных и настройте производительность своей базы данных
  • Регулярное обновление вашего Content Server — управление кластером используется уже много лет. У системного администратора просто нет оправдания тому, что он не пытается исправлять и улучшать свою систему.
  • Изучение вашей таксономии и модели метаданных. В этих тестах я не добавлял в смесь никаких дополнительных метаданных, но как только вы начинаете добавлять столбцы, деревья фасетов, с этим связан налог.
  • Разрешения — насколько некоторые клиенты «сходят с ума по метаданным», столько же «сходит с ума по разрешениям», добавляя сложные и замкнутые модели разрешений.
  • Брава — это еще одно обычное подозрение (и то, что я могу проверить позже), но просмотрщик, который не выдается бесплатно, также может повлиять на пользовательский опыт.

Умный интерфейс и классический

Другого способа выразить это нет. Smart UI на 2 секунды медленнее классического.

Я полагаю, что если бы был тюнинг, был бы шанс снизить это значение. Но реальность такова, что Smart UI более динамичен (на лету делается больше вещей), а сетевой трафик более болтлив (больше вызовов REST API).

CGI против LLISAPI

Этот меня заинтересовал. В плохих сетевых средах (вспомните глобальные сети в 2008 году) lliapi.dll всегда был самым производительным в этой области. Вы можете пострадать на стороне сервера, когда оборачиваете объект CGI, но я был удивлен, увидев, что это происходит быстрее (однако поля небольшие).

Apache Tomcat и IIS

Это больше всего выделялось из моих результатов. Особенно, если вы ищете способы сократить время работы Smart UI. Примечание. Приведенные ниже тесты были выполнены с использованием Apache Tomcat без сжатия.

Однако поля для повышения производительности меньше с классическим пользовательским интерфейсом.

О хай Апач Томкэт

Производительность Apache Tomcat стала для меня приятным сюрпризом. Тем более, что он полностью стандартный (кроме работы по протоколу HTTPS). Это означает, что этот сервер был:

  • срок действия содержимого не настроен.
  • Без сжатия, но по умолчанию Tomcat не включает сжатие

Мне нужно будет выполнить больше тестов — однако сейчас вот краткая диаграмма сравнения сжатия и/без сжатия.

Даже те, которые прошли тест без сжатия, превзошли тест на сжатие. Стоит помнить, что результат сжатия по-прежнему хорошо сравнивается с результатом IIS.

Общие результаты

Для теста 50 пунктов результаты были следующими:

  • Классический пользовательский интерфейс (Apache Tomcat 8.5/CGI/без сжатия) СРЕДНЕЕ 4,30472 с СРЕДНЕЕ 4,263 с
  • Классический пользовательский интерфейс (Apache Tomcat 8.5/CGI/сжатие) СРЕДНЕЕ 4,51155 с СРЕДНЕЕ 4,433 с
  • Классический пользовательский интерфейс (IIS/CGI) СРЕДНЕЕ 4,524 сек. СРЕДНЕЕ 4,522 сек.
  • Классический пользовательский интерфейс (IIS/LLISAPI) СРЕДНЕЕ 4,37972 сек. СРЕДНЕЕ 4,308 сек.
  • Smart UI (Apache Tomcat 8.5/CGI/без сжатия) СРЕДНЕЕ 6,71571 с СРЕДНЕЕ 6,666 с
  • Smart UI (IIS/CGI) СРЕДНЕЕ 7,27989 сек. СРЕДНЕЕ 7,2165 сек.

Для теста из 100 пунктов результаты были следующими:

  • Классический пользовательский интерфейс (Apache Tomcat 8.5/CGI/без сжатия) 4,36972 с
  • Классический пользовательский интерфейс (IIS/CGI) 4,64389 сек.
  • Классический пользовательский интерфейс (IIS/LLISAPI) 4,38877 сек.
  • Smart UI (Apache Tomcat 8.5/CGI/без сжатия) 7,12088 сек.
  • Smart UI (IIS/CGI) 7,42007 сек.

Время заключения

Для клиентской демонстрации — Smart UI поразит аудиторию. А для новых клиентов, которые никогда не использовали Content Server, интеллектуальная производительность пользовательского интерфейса может быть приемлемой. Однако для существующих клиентов, которые привыкли ожидать определенного уровня производительности, необходимость сказать им, что они должны подождать ~ 2 секунды, чтобы получить их контент, может оказаться на удивление сложной задачей.

Что касается развертывания Apache Tomcat через IIS — это потенциально стоит изучить, так как это потребуется большинству развертываний (например, OTDS, Archive Center, Brava). Однако выигрыш здесь с точки зрения классического пользовательского интерфейса, возможно, с разницей в 0,2 секунды, используя мои методы тестирования.

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

Можно ли исправить Smart UI?

Да, оно может. Но исправление будет не только на стороне клиента — однако есть ряд вещей, которые можно исправить и на стороне клиента.

В конечном счете, Smart UI очень болтлив. И каждый из этих запросов обращается к многопоточному серверу, потребляющему поток. Когда вы запускаете эти запросы асинхронно, не требуется много времени, чтобы перегрузить Content Server, если он не масштабируется должным образом (несмотря на конкуренцию на уровне базы данных). Может показаться, что Smart UI ориентирован на гибкость, в то время как более самоуверенный подход жестко запрограммировал бы больше параметров в коде, чтобы предотвратить болтовню.

Но не все так плохо

С появлением умного пользовательского интерфейса появился более богатый REST API, который теперь позволяет делать больше с классическим пользовательским интерфейсом.

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

Свяжитесь с Driver Lane в Twitter и LinkedIn или непосредственно на нашем веб-сайте.