Содержание


Проверенные методики IBM Business Analytics

Пакет тестирования стабильности IBM Cognos BI с использованием инструмента JMeter

Продукт: IBM Cognos BI 10.2; область интересов: производительность

Comments

Серия контента:

Этот контент является частью # из серии # статей: Проверенные методики IBM Business Analytics

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Проверенные методики IBM Business Analytics

Следите за выходом новых статей этой серии.

Назначение

Этот документ прилагается к файлу с планом тестирования стабильности IBM Cognos BI Server под заданной нагрузкой с использованием инструмента Apache JMeter. В документе представлена краткая информация об инструменте JMeter и создании отчетов в IBM Cognos BI, достаточная для понимания области применения и возможностей теста. Затем приводится детальное описание процесса использования Apache JMeter для выполнения предлагаемого плана тестирования и его конфигурирования под конкретную среду. Даются рекомендации в отношении выполнения теста, а также указания по интерпретации результатов и советы по решению проблем.

План и процесс тестирования, описанные в данном документе, успешно применялись в компаниях клиентов, а также в тестах масштабируемости, проводившихся специалистами IBM Cognos, и поэтому рассматриваются как рекомендованная методика.

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

  • Недоступно другое программное обеспечение для нагрузочного тестирования и проверки стабильности, такое как Rational Performance Tester или Mercury LoadRunner.
  • Система ведет себя нестабильно под нагрузкой, не все запросы выполняются успешно, наблюдается замедленное реагирование, появляются сообщения о непредвиденных ошибках и/или требуется механизм для стимулирования появления ошибок с целью решения проблем.
  • Установленное решение IBM Cognos BI требует проверки стабильности и функционирования под нагрузкой перед его переводом на следующий этап внедрения, такой как тестирование и подготовка к использованию в рабочей среде.
  • Требуется проверка стабильности, а также возможность быстро определить влияние конфигурационных и архитектурных изменений (таких как добавление экземпляра Report Service) на производительность.

Применимость

В предлагаемом плане тестирования необходимо использовать JMeter версии не ниже 2.7 (рекомендуется 2.9). План несовместим с более ранними версиями JMeter.

Как Java-приложение, инструмент JMeter доступен практически на любой платформе, поэтому план может выполняться на всех поддерживающих Java платформах.

Недавно этот план тестирования был проверен на различных операционных системах и конфигурациях. Он предназначен только для IBM Cognos BI версии 10.2.0. План подходит для задач тестирования вне зависимости от топологии, набора операционных систем и разрядности платформы. Полностью поддерживается использование Cognos Application Firewall (CAF), представляющее собой рекомендованную методику; настоятельно рекомендуется никогда не отключать CAF.

Ограничения и исключения

Предлагаемый план предназначен для указанных версий сервера IBM Cognos BI. С другими версиями IBM Cognos BI он может не работать в связи с внесением более или менее заметных изменений в запросы и синтаксис полезной нагрузки, а также с другими особенностями, которые могут меняться от версии к версии. Используйте этот план только для версий, перечисленных в данном документе. Для более ранних версий IBM Cognos BI существуют предыдущие версии этого пакета тестирования стабильности.

В настоящее время данный план тестирования выполняет отчеты из пакетов, поставляемых вместе с продуктом в составе IBM Cognos Viewer, включая следующие:

  • Отчеты Compatible Query Mode (CQM)
  • Отчеты Dynamic Query Mode (DQM)
  • Отчеты Dynamic Cube (DYNC)
  • Cognos Workspaces (см. детальное описание плана)

План не поддерживает:

  • Запуск каких-либо инструментов Studio
  • Active Reports
  • SSL-шлюзы
  • Механизм однократной аутентификации.

План тестирования предоставляется по принципу «как есть», с единственной целью предложить быстрый, универсальный и гибкий, бесплатный и простой способ проверки стабильности развернутого сервера IBM Cognos BI под нагрузкой. Формальная поддержка плана не предоставляется. Если вы заинтересованы в проведении подробных индивидуальных тестов работы под нагрузкой и настройки производительности, свяжитесь с региональным представителем IBM Cognos.

Этот план тестирования предоставляет стартовую точку для изучения стабильности и функционирования систем в сложных средах. Любой более серьезный анализ, в частности, анализ производительности, следует выполнять совместно с IBM Services и с использованием коммерческого инструмента для нагрузочного тестирования, такого как IBM Rational Performance Tester. В то же время результаты выполнения предлагаемого плана тестирования могут предоставить ценную информацию, указывающую на конфигурационные проблемы IBM Cognos BI, потребности в конфигурировании/настройке и возможные проблемы со стабильностью. Рекомендуется обязательно предоставлять эту информацию специалистам IBM для интерпретации обнаруженных признаков и решения любых проблем. IBM Cognos BI — это сложный продукт, поэтому результаты или проблемы, которые могут обнаружиться при выполнении этого плана тестирования, не обязательно будут следствием одной конкретной причины, и зачастую для корректной интерпретации результатов могут требоваться обширные знания архитектуры и процессов IBM Cognos BI. Настоятельно рекомендуется проводить поиск полученных сообщений об ошибках в IBM Information Center и на web-сайте IBM Cognos Support.

Допущения

Предполагается, что читатель знаком с концепциями, описанными в руководстве IBM Cognos BI Architecture and Security Guide, в частности, с компонентами и сервисами IBM Cognos BI.

Краткая информация

В этом разделе представлена некоторая базовая информация об инструменте JMeter и о процессе формирования отчетов в IBM Cognos BI, которая необходима для понимания условий выполнения плана и возможных результатов.

Apache JMeter

JMeter — это Java-инструмент, созданный в рамках проекта организации Apache по разработке программного обеспечения с открытым исходным кодом. Он предназначен для выполнения запросов к серверу и сбора полученных результатов. JMeter поддерживает HTML, XML, SOAP, JDBC и запросы других типов. Он может формировать множество параллельных потоков, а, значит, моделировать множество клиентов, обращающихся к системе. Он позволяет создавать планы тестирования вручную или записывая запросы сеанса одного клиента через посредническое приложение. Планы можно обогащать логикой программирования, такой как условное исполнение, обработка ответов с использованием регулярных выражений и т. д.

Ссылку на информацию об инструменте JMeter можно найти в разделе «Ресурсы» в конце этого документа. JMeter продолжает активно разрабатываться; периодически выпускаются новые версии. Хотя заявляется обратная совместимость новых версий, настоятельно рекомендуется использовать самую последнюю версию, содержащую исправления, улучшения производительности и более широкие функциональные возможности. За подробной информацией об использовании JMeter и назначении каждого из элементов плана обратитесь к документации по JMeter (см. раздел «Ресурсы»).

В JMeter используется концепция группы потоков (Thread Group) для моделирования набора клиентов, который проходит через определенную последовательность этапов. Один клиент представляется одним потоком, проходящим последовательные циклы через определенные этапы. Количество клиентских потоков в группе потоков можно настраивать. Один план тестирования может определять множество групп потоков, которые затем могут выполняться на разных экземплярах JMeter на отдельных системах. Однако в настоящее время невозможно ветвление множества потоков из этапа плана; такая функциональность могла бы потребоваться, например, для моделирования запросов типа AJAX на HTML-страницах.

Формирование отчетов в IBM Cognos BI

При формировании отчетов любого типа в IBM Cognos BI используется концепция «диалога» (conversation). Диалог — это операция с множеством этапов, каждый из которых технически является одиночным запросом. Таким образом, подготовка отчета превращается в серию запросов и ответов вместо одного запроса с одним ответом.

Каждый диалог начинается с первичного запроса (primary request) и может иметь один или множество вторичных запросов (secondary request), относящихся к этому же диалогу. Каждый диалог начинается в синхронном режиме, то есть отправитель запроса (клиент) ожидает ответа от получателя (сервиса). В течение этого времени клиент блокируется. Поскольку продолжать ожидание более нескольких секунд неэффективно, предусмотрен конфигурируемый порог Primary Wait Threshold (PWT), при достижении которого диалог переходит в асинхронный режим. С этого момента последовательность запросов меняется.

Когда диалог становится асинхронным, клиент для сохранения активности диалога должен отправлять вторичные запросы через заданные интервалы времени. Если вторичные запросы прекратятся, сервис-получатель остановит обработку текущего запроса и диалог завершится ошибкой, вместо выдачи результата. По умолчанию время ожидания для вторичного запроса составляет 30 секунд. Это пороговое значение времени ожидания называется Secondary Wait Threshold (SWT). Каждые 30 секунд клиент должен отправлять запрос ожидания к тому же сервису для сохранения активности диалога и для сообщения о том, что он все еще ожидает результата. Целевой сервис продолжает обработку и сообщает, когда обработка текущего запроса завершается и результат может быть извлечен клиентом. Количество требуемых итераций запросов ожидания полностью зависит от системных ресурсов. Если система значительно нагружена, например, при большом количестве одновременных пользователей, ей может потребоваться больше времени на обработку одного диалога, чем в случае только одного пользователя. Таким образом, при каждом запуске каждый диалог может выглядеть по-разному на уровне HTML в зависимости от фактической загрузки системы.

Это основная причина того, почему нельзя просто записать исполнение отчета IBM Cognos BI с использованием какого-либо инструмента типа JMeter или Rational Performance Tester и воспроизвести его для проведения тестирования. Если первичный запрос не завершился ответом в течение лимита времени PWT, диалог должен стать асинхронным, однако если это не зафиксировано, запрос окончится неудачей. Диалоги могут различаться по количеству требуемых запросов при каждом исполнении.

Все это отражается в запросах, которые образуют диалог. Если клиентом является браузер, выполняющий инструмент IBM Cognos Viewer, то обработку диалога обеспечивает код JavaScript, встроенный в HTML-страницы, которые формируют инструмент IBM Cognos Viewer. Если клиентом является программа IBM Cognos SDK, обработка диалога должна быть реализована самим клиентом. Это применимо и к плану JMeter. План JMeter должен имитировать функциональность JavaScript, передавая конкретные переменные HTML-форм и динамично реагируя на их содержимое в соответствии с ответами сервера.

Диалоги используются всегда, когда что-то исполняется— например отчеты, агенты, анализ и рабочие пространства. Когда сервисы IBM Cognos взаимодействуют друг с другом, также происходят диалоги, и каждый из сервисов реализует клиентскую часть обработки диалога.

Подробные сведения об обработке диалогов в клиентском приложении представлены в руководстве IBM Cognos SDK Developer Guide, входящем в состав продукта IBM Cognos SDK. Однако для целей данного документа изложенной выше информации достаточно.

Подготовка среды

Настройка среды тестирования

Выполнение теста JMeter имеет ряд требований в отношении самого инструмента и настройки IBM Cognos BI.

Куда устанавливать JMeter

В процессе тестирования приложение JMeter моделирует клиентов, одновременно подключающихся к IBM Cognos BI с использованием HTTP-клиента. JMeter порождает поток для каждого моделируемого клиентского сеанса (одновременного пользователя), поэтому потребуются ресурсы процессоров и оперативной памяти, достаточные для исключения узких мест на стороне JMeter. Платформы с поддержкой ускоренной поточной обработки, такие как Linux, как правило, лучше справляются с этой задачей. Больший объем памяти также положительно сказывается на производительности JMeter, поскольку позволяет выполнять переключение контекста в памяти. Как правило, процессора с тактовой частотой не менее 1,5 ГГц и оперативной памяти объемом не менее 2 ГБ достаточно для поддержки работы JMeter в сценарии моделирования около 30 клиентов. Фактические потребности зависят от количества моделируемых клиентов. Эта рекомендация основывается на опыте, а не на официальном широкомасштабном тестировании.

Для максимально эффективного тестирования приложение JMeter рекомендуется выполнять на отдельной машине, где не установлены компоненты IBM Cognos BI или базы данных. Как уже отмечалось, в зависимости от количества пользователей, которое вы хотите смоделировать, может существовать большое количество потоков и используемых сокетов, что может оказывать значительное влияние на производительность машины. Если система также занята выполнением компонентов IBM Cognos BI, отвлекать ресурсы на выполнение JMeter неразумно.

Реализация IBM Cognos BI Gateway

Моделируя множество клиентов, получающих доступ к IBM Cognos BI через шлюз, необходимо обратить внимание на следующее. В случае CGI-шлюза web-сервер будет порождать по одному экземпляру исполняемой программы CGI для каждого клиентского сеанса. Каждый экземпляр будет отдельным процессом со своими собственными памятью и ресурсами. Поэтому рекомендуется следовать рекомендованной методике и использовать IBM Cognos BI Gateway не в CGI-реализации, а в вариантах MOD, MOD2 или MOD2_2 для web-серверов Apache или ISAPI для Microsoft IIS, поскольку они значительно эффективнее используют ресурсы и специально запрограммированы для обеспечения высокой производительности. CGI-шлюзы являются универсальными и поддерживаются любым web-сервером, но они не подходят для производственных систем, тем более для систем с большой нагрузкой. План тестирования будет работать с любым шлюзом IBM Cognos BI Gateway, а также непосредственно с IBM Cognos Dispatcher, однако моделирование множества (более 30) одновременных клиентских сеансов может перегрузить вашу точку входа.

Использование инструментов мониторинга

При тестировании с применением предлагаемого плана рекомендуется внимательно следить за потреблением ресурсов на уровне операционной системы и на уровне запросов и/или базы данных Content Manager. Повышение нагрузки на систему может выявить узкие места или проблемы, о которых вы прежде не знали. У вас должны быть права доступа и привилегии, достаточные для использования инструментов администрирования, таких как IBM DB2 Control Center, IBM Data Studio, Oracle Enterprise Manager, Microsoft SQL Enterprise Console и команды мониторинга операционных систем.

Запустите браузер на отдельной машине и используйте инструмент IBM Cognos Administration для мониторинга:

  • количества порождаемых процессов Report Service
  • количества потоков, открываемых для каждого процесса Report Service
  • количества потоков, открываемых для IBM Cognos BI Services
  • количества подключений к базе данных контента
  • потребления памяти для Content Manager и компонентов Dispatcher
  • количества интерактивных задач
  • потребления памяти процессом Query Service
  • соотношения попаданий/промахов для кэш-памяти Dynamic Cubes.

Этот список неполон, но для начала его достаточно. Для более детального мониторинга IBM Cognos BI с использованием расширений Java Monitoring Extensions (JMX) воспользуйтесь ссылкой на методологию System Management Methodology в разделе «Ресурсы».

Выполнение предварительных условий

Установка JMeter

JMeter — это Java-инструмент, и для его использования вам потребуется Java Runtime Environment (JRE). Для JMeter версии 2.7 и выше требуется JRE версии не ниже 1.6. После установки JMeter вам нужно сконфигурировать его на использование соответствующей JRE. Более подробную информацию о предварительных требованиях для JMeter, о его установке и использовании можно найти в руководстве JMeter User Manual (см. раздел «Ресурсы»).

Предлагаемая версия плана была разработана в JMeter 2.7 и 2.9 с использованием IBM JRE 1.6.0 64-bit на Red Hat Enterprise Linux и Microsoft Windows 2008-64.

Установка требуемых пакетов IBM Cognos BI

Предлагаемый план тестирования исполняет отчеты из следующих примеров, поставляемых с IBM Cognos BI:

  • IBM_Cognos_Samples
    Пакеты Go Data Warehouse (запрос), GO Data Warehouse (анализ) и Go Sales Query
  • IBM_Cognos_Samples_DQ
    Пакеты GO Data Warehouse (анализ) и Go Sales Query
  • IBM_Cognos_Power_Cube
    Пакет Sales and Marketing (куб)
  • IBM_Cognos_DynamicCube
    Пакет Go Data Warehouse Sales.

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

Пакеты GO Data Warehouse и пакет GO Sales используют реляционные источники данных, которые могут потребовать некоторой дополнительной настройки, а пакет Sales and Marketing основывается на IBM Cognos PowerCube и никакой дополнительной настройки не требует.

Инструкции по установке этих пакетов можно найти в приложении D к руководству IBM Cognos 10.2 Installation and Configuration Guide или в онлайновом информационном центре IBM Cognos 10.2 по адресу:
http://pic.dhe.ibm.com/infocenter/cbi/v10r2m0/topic/com.ibm.swg.ba.cognos.inst_cr_winux.10.2.0.doc/c_settingupsamplesbi.html?path=0_16_23_2#SettingUpSamples

Инструкции по установке примеров для динамических кубов можно найти в главе 3 руководства Dynamic Query Guide или в онлайновом информационном центре IBM Cognos 10.2 по адресу:
http://pic.dhe.ibm.com/infocenter/cbi/v10r2m0/topic/com.ibm.swg.ba.cognos.ig_rolap.10.2.0.doc/C_ig_rolap_sample_setup.html

Конфигурирование плана тестирования

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

Рисунок 1. Развернутое дерево элементов плана тестирования
Illustration 1: JMeter expanded tree of test plan elements
Illustration 1: JMeter expanded tree of test plan elements

В JMeter версии 2.1.2 по умолчанию развертываются все элементы дерева. Это затрудняет получение общего представления о плане тестирования, поэтому рекомендуется отключить в JMeter развертывание всех элементов при запуске. Для этого запускайте JMeter с ключом -Jonload.expandtree=false, либо отредактируйте файл jmeter.properties, добавив строку onload.expandtree=false.

Когда JMeter откроется, разверните узел верхнего уровня IBM Cognos 10.2.0 – BI Stability package. Вы увидите еще один узел с тем же именем; разверните его. Теперь разверните элемент Overall Tests, и тогда вы получите хорошее общее представление плана, как показано на рисунке 2.

Рисунок 2. Свернутое дерево элементов плана тестирования с запросами Logon/Logoff. Запросы, которые будут выполняться, и конфигурационные свойства выделены цветными границами.
Illustration 2: JMeter collapsed tree of test plan elements with the logon/logoff requests, the requests to be executed and configuration properties highlighted by colored borders
Illustration 2: JMeter collapsed tree of test plan elements with the logon/logoff requests, the requests to be executed and configuration properties highlighted by colored borders

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

Как показано на рисунке 2, основной элемент конфигурации Test configuration Parameters (выделен красным цветом) используется в настройке плана под конкретную среду путем редактирования его свойств (выделены желтым цветом). Более подробная информация об этих конфигурационных настройках будет представлена в разделе Конфигурирование параметров. Сам тест имеет два элемента, обрабатывающих запросы на вход в систему и выход (выделены зеленым цветом), которые будут описаны в разделе Конфигурирование параметров, и 15 элементов, исполняющих отчет (выделены голубым цветом), которые будут обсуждаться в следующем разделе.

Понимание структуры плана и отключение конкретных тестов

Этот план тестирования формирует 15 разных отчетов с использованием разных форматов вывода результатов. Некоторые отчеты включают запросы значений. Далее приведен список отчетов с информацией об исполнении каждого из них, касающейся этапов и формата вывода результатов. Имейте в виду, что графики и представления результатов в виде двоичных файлов (в форматах Excel, CSV или PDF) формируются сервером Report Server и передаются клиенту в виде двоичного файла в ответ на явный запрос GET. В браузере это будут обеспечивать элементы iframe или JavaScript, направляя такие запросы GET конкретному сервису, который предоставляет эти элементы из внутренней кэш-памяти, где они были созданы.

Отчеты с использованием режима динамических запросов (Dynamic Query Mode, DQM) начинаются с элемента 10, отчеты с использованием динамических кубов (DYNC) начинаются с элемента 20, а отчеты для рабочих пространств (Workspace) начинаются с элемента 30.

  1. Budget vs Actual, GO Data Warehouse (анализ)
    • Исполняется в формате HTML.
    • Не включает запросов значений.
    • Одна операция перехода на следующую страницу, как только будет обработана первая страница.
    • Очень простой отчет в виде перекрестной таблицы.
  2. Order Invoices - Donald Chow, Sales Person, GO Sales (запрос)
    • Исполняется в формате PDF.
    • Не включает запросов значений.
    • Из хранилища контента извлекается файл PDF (257 страниц).
    • Простой отчет в виде списка, достаточно объемный, с небольшой компоновкой и фирменной символикой.
  3. Planned Headcount, GO Data Warehouse (анализ)
    • Исполняется в формате HTML.
    • Не включает запросов значений.
    • Отчет содержит 5 диаграмм. План загружает изображения диаграмм в формате GIF для имитации просмотра HTML-отчета.
  4. Global Bonus Report, Go Data Warehouse (анализ)
    • Исполняется в формате HTML.
    • Имеет одну страницу с запросом двух параметров (год и регион). Используются значение 2005 для года и Americas для региона.
    • Отчет в виде списка.
  5. Pension Plan, GO Data Warehouse (запрос)
    • Исполняется в формате CSV.
    • Нет запросов значений.
    • Отчет в виде списка с большим количеством данных.
  6. Recruitment Report, GO Data Warehouse (анализ)
    • Исполняется в формате XLWA.
    • Имеет одну страницу с запросом одного параметра (год). Используется значение 2006.
    • Отчет содержит несколько диаграмм и одну таблицу.
  7. Historical Revenue, Sales and Marketing (куб)
    • Исполняется в формате HTML.
    • Имеет две страницы с запросами по одному параметру на каждой. Первая страница запрашивает год, вторая — месяц года, выбранного на первой странице. Используются значения 2006 для года и June для месяца.
    • Отчет в виде одной диаграммы, которая извлекается явным образом отдельным запросом GET.
  8. Customer Returns and Satisfaction, GO Data Warehouse (анализ)
    • Отчет с использованием Dynamic Query Mode.
    • Исполняется в формате HTML.
    • Нет страниц с запросами значений, но выполняется операция перехода на следующую страницу, как только становятся доступны результаты первой страницы.
    • Отчет включает две диаграммы и два списка, диаграммы извлекаются явным образом отдельным запросом GET.
  9. Return Quantity by Order Method, GO Data Warehouse (анализ)
    • Отчет с использованием Dynamic Query Mode.
    • Исполняется в формате XLWA.
    • Содержит одну перекрестную таблицу.
  10. Employee Training by Year, GO Data Warehouse (анализ)
    • Отчет с использованием Dynamic Query Mode.
    • Исполняется в формате HTML.
    • Имеет две страницы с запросами значений, первая для года, вторая для квартала этого года. Используются значения 2012 для года и 3 для квартала.
    • Отчет содержит диаграмму и перекрестную таблицу. Диаграмма извлекается отдельным запросом GET.
  11. Order Invoices – Donald Chow, GO Sales (запрос)
    • Отчет с использованием Dynamic Query Mode.
    • Исполняется в формате PDF.
    • Нет запросов значений.
    • Отчет содержит большой список, а поскольку он имеет формат PDF, все результаты должны быть загружены.
  12. Revenue by order method and region, GO Data Warehouse Sales
    • Использует динамический куб.
    • Исполняется в формате PDF.
    • Нет запросов значений.
    • Небольшой отчет, содержащий перекрестную таблицу. Идеален для масштабирования.
  13. Revenue by retailer and product line, GO Data Warehouse Sales
    • Использует динамический куб.
    • Исполняется в формате HTML.
    • Нет страниц с запросами значений, но выполняется операция перехода на следующую страницу, как только становятся доступны результаты первой страницы.
    • Отчет содержит большой список.
  14. Sales by Year Workspace, Cognos Workspace Samples folder
    • Отчет Workspace.
    • Содержит 9 виджетов, из которых 6 формируют диаграммы.
    • Виджеты исполняются последовательно, диаграммы извлекаются явным образом отдельным запросом GET.
  15. Marketing Workspace, Cognos Workspace Samples folder
    • Отчет Workspace.
    • Содержит 6 виджетов, из которых 3 формируют диаграммы, а также одну перекрестную таблицу.
    • Виджеты исполняются последовательно, диаграммы и перекрестная таблица извлекаются явным образом отдельным запросом GET.

План тестирования отображается в виде иерархической древовидной структуры. Верхним элементом является Overall Test, который содержит все подэлементы. Эти подэлементы пронумерованы. Элементы 00 и 99 используются только для аутентификации (более подробные сведения представлены в разделе Конфигурирование аутентификации). Все остальные элементы исполняют отчет или рабочее пространство. Если вы хотите исключить отчет из теста, просто щелкните правой кнопкой мыши по элементу и в контекстном меню выберите вариант Disable (см. рисунок 3). Отключенные отчеты в ходе тестирования будут пропущены.

Рисунок 3. Контекстное меню, вызываемое правой кнопкой мыши, с вариантом Disable для выбранного элемента
Illustration 3: JMeter's right-click context menu showing the Disable option for the selected element
Illustration 3: JMeter's right-click context menu showing the Disable option for the selected element

Вы увидите, что отключенный элемент на левой панели станет серым. Вы можете снова активизировать этот элемент через это же контекстное меню, щелкнув по элементу правой кнопкой мыши и выбрав Enable. Последние версии JMeter предлагают функцию Toggle, которой назначена удобная комбинация клавиш вызова (CTRL + T) для переключения между статусами «включен»/»отключен».

Поскольку план тестирования можно рассматривать как иерархическое дерево, один элемент, или узел, может содержать другие узлы, которые становятся дочерними элементами в этом контексте. Частью плана тестирования, которая исполняет отчеты, является элемент Overall Tests типа transaction controller. По сути это означает, что все его дочерние элементы воспринимаются как одна операция в отношении измерения времени исполнения и результатов. Этот верхний элемент включает по одному нумерованному подэлементу для каждого отчета, исполняемого в ходе тестирования,— все такие подэлементы отчетов имеют тип transaction controller. Это позволяет узнавать общее время для всех этапов диалога, исполняющего конкретный отчет, вне зависимости от деталей и этапов отчета. Для примера рассмотрим план, сконфигурированный для исполнения только подэлементов 01 и 02. В этом случае элементы типа transaction controller будут предоставлять общее время выполнения всех этапов, необходимых для формирования отчета Report_1, общее время выполнения всех этапов, необходимых для формирования отчета Report_2 и общее время выполнения всего теста.

В самом конце плана тестирования вы найдете два элемента Listener. Эти элементы будут фиксировать каждый запрос и полученный ответ и будут представлять эти данные в удобном для пользователя виде. Элемент View Result Tree покажет запросы в виде дерева, а элемент Aggregate Report создаст представление, похожее на отчет в виде списка. В разделе Интерпретация результатов приведены более подробные сведения об элементах Listener. Правым щелчком мыши можно добавлять элементы Listener, выбирая их из категории Listener, включающей диаграммы и статистические представления. За дополнительной информацией обращайтесь к документации по JMeter.

Конфигурирование параметров

Элемент Test configuration Parameters является одной из двух областей редактирования параметров для настройки плана под конкретную среду. Как правило, необходимо указать следующие пять параметров в соответствии с характеристиками среды:

  • Servername
    Укажите имя NetBIOS или полное имя сервера для вашей точки входа в IBM Cognos BI. Это может быть URI-идентификатор компонента Gateway или Dispatcher.
  • Port
    Сетевой порт для точки входа.
  • url
    URL-адрес точки входа для IBM Cognos BI. Обычно это путь, следующий за именем сервера, включая первый символ «/». Для IBM Cognos Gateway он будет иметь вид /<alias>/cgi-bin/<gateway_executable>. Например, /ibmcognos/cgi-bin/mod2_2_cognos.so. Для IBM Cognos BI Dispatcher —/<context_root>/servlet/dispatch/ext. Например: /p2pd/servlet/dispatch/ext
  • Namespace
    Идентификатор пространства имен, которое используется, если необходима аутентификация для доступа к IBM Cognos BI. Если сконфигурированных пространств имен несколько, то для аутентификации может быть выбрано только одно. Использование нескольких пространств имен планом не поддерживается. Идентификатор пространства имен может быть получен из IBM Cognos Configuration. Если вы не будете использовать аутентификацию, оставьте это поле пустым. За более подробными сведениями обратитесь к разделу Конфигурирование аутентификации.
  • Templocation
    В IBM Cognos BI версии 10.1 временные объекты для исполнения отчетов теперь хранятся не в Content Store, а в локальной файловой системе. Это означает, что по умолчанию диаграммы, графики и другие двоичные данные, являющиеся компонентами отчета, хранятся во временном каталоге Cognos, сконфигурированном локально с использованием IBM Cognos Configuration, а не в Content Store, как было в IBM Cognos 8 BI. Это меняет URL-адреса, используемые для извлечения этих компонентов при отображении отчета. План тестирования должен быть настроен в соответствии с конфигурацией IBM Cognos 10 BI, чтобы обеспечивать извлечение диаграмм и двоичных данных. Если этот параметр определен некорректно, то в итоговом древовидном представлении не будет никаких примеров, обозначенных как Retrieve graph output. Это не приведет к неудаче при исполнении плана, однако может искажать результаты или препятствовать выявлению ошибок сервиса Graphics Service при построении диаграмм, поскольку потерянные диаграммы не будут ожидаться. Обязательно указывайте в Templocation значение FS, если только решение IBM Cognos 10 BI не было сконфигурировано на использование Content Store для хранения таких временных объектов; в этом случае в поле Templocation следует указать CM. На рисунке 4 показан выбор значения для параметра Temporary objects location в инструменте IBM Cognos Administration.
    Рисунок 4. IBM Cognos Administration с параметром Server File System, выбранным по умолчанию для размещения временных объектов
    Illustration 4: IBM Cognos Administration showing for the Temporary object location being set to the default value of Server File System
    Illustration 4: IBM Cognos Administration showing for the Temporary object location being set to the default value of Server File System

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

  • Outputlocale
    Вы можете указать местоположение результатов исполнения отчетов, заменяя соответствующий параметр в профиле учетной записи пользователя IBM Cognos 10 BI, используемой планом тестирования для входа в систему.
  • pwt
    Указывает пороговое значение Primary Wait Threshold (PWT) для диалога при исполнении отчета. IBM Cognos Viewer использует значение 3 секунды, другие клиенты обычно используют 7 секунд. Выбор значения 0 (ноль) запрещает перевод диалога в асинхронный режим, блокируя тем самым ресурсы в системе, чтобы каждый пользовательский поток ожидал результата запроса. Эта настройка приводит к снижению производительности, однако иногда используется для устранения неполадок.
  • swt
    Указывает пороговое значение Secondary Wait Threshold (SWT) для диалога при исполнении отчета. По умолчанию установлено значение 30 секунд, и его не следует менять. Уменьшение этого значения не поможет ускорить извлечение результатов, поскольку любой сервис может сообщать ожидающему клиенту о завершении работы над запросом независимо от значения SWT. Увеличение этого значения не обязательно обеспечит более экономное использование ресурсов благодаря менее частым отправкам повторных запросов. Этот параметр предназначен в основном для устранения неполадок.

Конфигурирование аутентификации

Если тест не включает аутентификацию — то есть IBM Cognos 10 BI допускает анонимный доступ, — то в элементе Test configuration Parameters поле параметра Namespace нужно оставить пустым. План тестирования будет реагировать соответствующим образом и пропускать этап аутентификации, что автоматически делает сеанс анонимным.

Если тест включает аутентификацию, то в поле параметра Namespace элемента Test configuration Parameters необходимо указать идентификатор пространства имен для аутентификации, как описано выше в разделе Конфигурирование параметров.

Кроме того, потребуется предоставить имена пользователей и пароли, которые будут использоваться планом для создания аутентифицированных сеансов подключения к IBM Cognos BI. Поскольку план не поддерживает механизм единой регистрации (Single Sign-on) для IBM Cognos BI, то требуются учетные данные в явном виде, например, имя пользователя и пароль.

При исполнении плана каждый поток будет моделировать сеанс одного пользователя. Для аутентификации такого сеанса необходима действующая учетная запись пользователя IBM Cognos BI. Поскольку IBM Cognos BI поддерживает множество одновременных активных сеансов одного пользователя, теоретически весь план тестирования может быть выполнен с использованием одной учетной записи пользователя. Однако лучше использовать учетную запись одного пользователя параллельно не более 5 раз. В идеале для более эффективного решения проблем и повышения качества тестирования в отношении аудита результатов и обеспечения схожести с реальным многопользовательским сценарием каждый клиентский сеанс, моделируемый JMeter, должен использовать отдельный набор учетных данных пользователя. Это особенно важно, если принять во внимание влияние кэширования данных пользователя, которое может происходить в продукте.

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

При небольшом количестве наборов учетных записей удобно использовать элемент User Parameters в инструменте JMeter. Этот элемент позволяет указывать определенный набор переменных для каждого пользователя в простой таблице. В первом столбце Name определяется набор параметров, по одному в строке, и каждый дополнительный столбец определяет отдельного пользователя.

Для данного плана необходимо определить две переменные, user и pass, с целью хранения имени пользователя и соответствующего пароля. Например, для теста с 5 наборами учетных записей потребуется в этом элементе определить таблицу с 2 строками и 5 столбцами, без учета первого столбца Name. Нажимая на кнопку Add User, можно добавлять столбцы, которые JMeter помечает автоматически (см. рисунок 5). User_1 имеет атрибут user со значением some_user и атрибут pass со значением some_password.

Рисунок 5. Элемент User Parameters, содержащий таблицу, которая определяет учетные данные для одного пользователя
Illustration 5: The User Parameters element of the plan containing a table defining a single user's  credentials
Illustration 5: The User Parameters element of the plan containing a table defining a single user's credentials

Если будут использоваться несколько наборов учетных записей пользователей, то лучше указывать имена пользователей и пароли в отдельном CSV-файле. В этом случае нужно создать простой текстовой файл, который должен храниться в том же каталоге, что и сам план тестирования. В CSV-файле необходимо задать имена пользователей и пароли, по одному набору учетных записей в каждой строке, оканчивающейся парой разделителей CR/LF. В JMeter деактивируйте элемент User Parameters, щелкнув по нему правой кнопкой мыши и выбрав Disable, а затем активируйте элемент CSV Data Set Config с именем User Credentials File, щелкнув по нему правой кнопкой мыши и выбрав Enable. Как показано на рисунке 6, в поле Filename элемента CSV Data Set Config укажите имя CSV-файла, содержащего учетные данные пользователей. Если CSV-файл сохранен в том же каталоге, что и файл плана тестирования, достаточно указать только имя файла, поскольку относительные имена файлов определяются относительно пути к файлу плана. Для параметра Variable Names необходимо указать user,pass, это будет означать, что каждая строка, считываемая из этого файла, будет содержать два строчных элемента, разделенные запятой. Первый будет использоваться как имя пользователя, второй как пароль. Важно понимать, что пароли будут храниться в виде открытого текста, и шифрование этого файла не обеспечивается, поэтому потребуется соответствующим образом защитить доступ к этому CSV-файлу с использованием средств безопасности файловой системы.

Рисунок 6. Свойства элемента CSV Data Set Config с именем User Credentials File
Illustration 6: The CSV Data Set Config element labelled User Credentials File showing the element's properties
Illustration 6: The CSV Data Set Config element labelled User Credentials File showing the element's properties

Используемый в данном примере CSV-файл 102users.txt будет выглядеть примерно так:

user1,password1
user2,password2
…
user99,password99

Не забывайте о том, что по умолчанию пробелы не игнорируются, поэтому случайные пробелы после разделяющей запятой могут привести к ошибкам входа. Если в строчных элементах требуются скобки или пробелы, заключите их в кавычки, а в поле Allow quoted data? элемента CSV Data Set Config установите значение True.

При исполнении плана каждый поток будет считывать одну строку из этого файла. Используя опцию Recycle on EOF, можно установить переход к началу при достижении конца CSV-файла либо прекращение считывания значений. Настоятельно рекомендуется активировать опцию Recycle on EOF для предотвращения ошибок аутентификации в связи с отсутствием учетных данных.

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

Конфигурирование количества потоков и увеличения нагрузки

По умолчанию план тестирования выполняет один поток и один раз проходит по всем активированным элементам плана. Вероятнее всего, вам потребуется моделировать множество пользователей, поэтому необходимо увеличить количество потоков и, возможно, количество итераций. Это можно сделать, щелкнув в дереве по второму элементу пакета IBM Cognos 10.2.0 — BI Stability. Это элемент типа Thread Group, который обсуждался в начале документа.

Рисунок 7. Свойства элемента Thread Group, включая количество потоков, период увеличения нагрузки и количество циклов
Illustration 7: The properties of the Thread Group element including number of threads, ramp-up period and loop count
Illustration 7: The properties of the Thread Group element including number of threads, ramp-up period and loop count

Свойства элемента Thread Group будут показаны в правой части JMeter. В них можно указать количество потоков number of threads, период увеличения нагрузки ramp-up period и количество циклов выполнения плана тестирования loop count (см. рисунок 7). JMeter будет распределять создание новых потоков равномерно по указанному периоду увеличения нагрузки. То есть в случае 5 потоков и периода увеличения нагрузки в 60 секунд новый поток будет создаваться каждые 12 секунд, пока не будет достигнуто сконфигурированное количество потоков.

Помимо этого, можно настроить параметр Action to be taken after a Sampler error, чтобы указать, какое действие нужно выполнять, когда поток сталкивается с ошибкой. Для этого параметра установлено значение Stop Thread (Остановить поток), и вам не следует его менять, поскольку это позволит легко идентифицировать ошибки, возникающие в ходе выполнения теста. План создан для проверки успешности выполнения запроса. Если результат является чем-то непредвиденным, то поток остановится, и вы сможете точно определить, в каком месте плана это произошло.

Возможное максимальное количество потоков зависит от доступных ресурсов системы, на которой выполняется JMeter. Безусловно, даже если JMeter будет способен запускать сотни потоков, это не означает, что тестируемая система IBM Cognos BI будет способна их обработать, поэтому лучшей методикой является увеличение количества потоков постепенно, с каждым очередным выполнением плана тестирования. Период увеличения нагрузки будет оказывать значительное влияние на уровень параллелизма, уменьшение этого периода может легко привести к перегрузке как машины, на которой выполняется JMeter, так и целевой системы, поэтому рекомендуется постепенный подход.

Хорошей практикой использования/разработки плана является запуск с одним пользователем и одной итерацией. Если все работает, то можно идти дальше, увеличив количество пользователей до 10 и установив период наращивания нагрузки в 60 секунд. BI-система на базе одного сервера должна быть способна как минимум успешно выполнять аутентификацию всех сеансов — остальное зависит от исполняемых отчетов.

Тестирование

План тестирования можно запускать и останавливать через меню Run.

Вся активность (например, результат каждого отдельного запроса) будет фиксироваться двумя элементами Listener. Хорошей практикой является очистка записанных данных перед выполнением каждого теста. Это можно сделать, зайдя в меню Run и выбрав Clear All. Можно использовать комбинации клавиши CTRL+E для очистки результатов теста и CTRL+S для запуска теста. Тест можно остановить в любое время командой Stop в меню Run или сочетанием клавиш CTRL+. (точка). В случае большого количества активных потоков остановка теста может занять некоторое время.

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

Рисунок 8. Панель статуса JMeter: справа отображаются индикатор активности и счетчик потоков
Illustration 8: JMeter Status bar showing the activity indicator and thread counters to the farmost right
Illustration 8: JMeter Status bar showing the activity indicator and thread counters to the farmost right

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

Обычно после запуска теста вы щелкаете по одному из элементов Listener для мониторинга процесса тестирования. Элемент Aggregate Report предлагает сводную информацию, а элемент View Result Tree выводит в виде дерева все отправленные запросы и полученные ответы. Дерево динамично обновляется и поэтому растет по мере выполнения теста.

Важно отметить, что элемент будет появляться в дереве результатов только после отправки запроса и 1) получения ответа или 2) возникновении ошибки при выполнении запроса. Например, если вы не видите начального элемента Login, то это может быть вызвано тем, что вы пытаетесь подключиться к неправильному URL-адресу и время ожидания ответа от web-сервера составляет 30 секунд.

Можно щелкать по каждому элементу дерева результатов, и на правой панели будет отображаться информация о результате (технические сведения, такие как заголовки и количество переданных байт), об отправленном запросе (точный URL-адрес запроса и переданная информация) и полученные данные, в отдельных вкладках (см. рисунок 10). Изучение ответов позволит узнать причины ошибки при выполнении определенного элемента или какие данные были возвращены. JMeter может выводить данные ответов в разных форматах для удобства просмотра, а также предоставляет возможность поиска данных ответов с использованием регулярных выражений.

Некоторые элементы не будут иметь ответа, поскольку они не формируют запросов, а только структурируют запросы плана тестирования. Одним из примеров являются элементы типа transaction controller. Они появляются в плане, но у них не будет результата, относящегося к HTTP-запросу и ответу. Они лишь структурируют план и подсчитывают общее время.

Если запрос в дереве результатов выделен красным цветом, это означает, что выполнение запроса закончилось неудачей и поток, создавший запрос, был остановлен. Изучение вкладки с данными ответа на этот запрос позволит получить информацию о причине остановки.

Вы можете заметить, что в дереве результатов Listener элементы будут появляться не по порядку. Это связано с тем, что при обработке иерархической древовидной структуры плана сначала выполняются дочерние элементы. Только после обработки всех дочерних элементов будет рассматриваться родительский элемент. Поэтому родительский элемент будет показан после всех своих дочерних элементов. На рисунке 9 представлено дерево результатов.

Рисунок 9. Дерево результатов Listener, показывающее ответы в виде списка нумерованных элементов с отступами
Illustration 9: The result tree Listener output showing responses in an indented list of numbered elements
Illustration 9: The result tree Listener output showing responses in an indented list of numbered elements

Использование отступов и нумерации позволяет упростить просмотр дерева результатов. Каждый элемент имеет номер, каждому дочернему элементу присваивается этот же номер с добавлением номера второго уровня, отделенного точкой. Кроме того, дочерние элементы сдвинуты вправо несколькими пробелами, в соответствии с уровнями иерархии. Например, x.1 означает первый подэлемент элемента x, он отображается сдвинутым на 3 пробела вправо. Эта схема применяется ко всем элементам, с использованием до 5 уровней отступов и нумерации.

Рассмотрим в плане элемент Logon с номером 00 (ноль ноль). Этот элемент имеет два дочерних элемента 0.1 и 0.2. Первый дочерний элемент вложен в условие, то есть он будет исполняться только при выполнении этого условия. В дереве результатов этот элемент Logon появляется в виде одной или двух записей для подэлементов, в зависимости от того, используется ли анонимная аутентификация. Если используется, то элемент 0.1 не будет исполняться. В дереве результатов элемент Logon появится только после этих дочерних элементов, если выполнение Logon завершилось успешно. Поэтому при чтении сверху вниз появление элемента 00 свидетельствует об успешном завершении обработки элемента Logon. Если на каком-либо этапе аутентификация завершится неудачей, то родительский элемент 00 для Logon будет отсутствовать, а один из дочерних элементов будет выделен красным цветом и снабжен символом предупреждения. Агрегированные элементы, такие как 00 - Logon, отображаются без отступа, и понятно, что с отступом будут отображаться блоки или группы, сформированные для каждого элемента плана. На рисунке 10 показаны красные прямоугольники вокруг блоков для элементов 00–03.

Элемент Aggregate Report Listener представляет результаты в виде таблицы, показывая по одной строке для каждого отдельного элемента теста со столбцами, содержащими несколько значений времени, таких как минимум, максимум, медиана и среднее время. Это позволяет узнавать информацию о времени исполнения всего отчета, а также детальную информацию для конкретных элементов или даже некоторых больших этапов исполнения (см. рисунок 10). Кроме этого, можно изучить, как часто исполнялся элемент, и определить, пройдены ли все сконфигурированные потоки для конкретных элементов.

Рисунок 10. Элемент Aggregate Result Listener с результатами в табличном виде
Illustration 10: The Aggregate Result Listener displaying the table like output
Illustration 10: The Aggregate Result Listener displaying the table like output

И в заключение еще одно пояснение в отношении результатов, предоставляемых элементами Listener. При выполнении тестов с использованием только одного потока (пользователя) порядок записей, появляющихся в Aggregate Result Listener или View Result Tree Listener, будет отражать структуру плана тестирования так, как было описано выше. Если тест использует множество потоков, то последовательность записей в обоих элементах Listener может выглядеть беспорядочной. Это не проблема с планом, это вызвано тем, что множество потоков выполняются одновременно. Они будут независимо друг от друга вносить новые результаты в Listener, и поэтому запись с большим номером может появляться перед записью с меньшим номером, просто потому, что потоки исполняют разные элементы плана. Это ожидаемое поведение, и оно характерно в особенности для элементов, которые исполняют асинхронный диалог. Такие элементы могут появляться позже в ходе исполнения плана, поскольку при увеличении нагрузки на систему для обработки запросов, которые прежде выполнялись почти мгновенно, теперь требуется несколько секунд. Можно было бы помечать результаты элементов номерами их потоков, однако это внесло бы путаницу в план, и автор решил этого не делать. При необходимости можно снабдить каждый элемент префиксом [{$__threadNum}] для добавления в результат номера исполняемого потока в группе потоков.

Интерпретация результатов

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

Поскольку нашей целью является обеспечение стабильности, столбец ошибок должен содержать только записи 0%. Если в какой-то строке есть ошибки, то столбец ошибок будет показывать значение, отличное от 0%. Перейдите в элемент View Result Tree Listener и найдите записи, выделенные красным цветом. Изучайте ответы и реагируйте на сообщения об ошибках, настраивая конфигурацию IBM Cognos 10 BI или системные параметры.

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

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

Если результаты теста содержат какие-либо ошибки, это не обязательно означает, что целевая система IBM Cognos BI нестабильна. Это просто свидетельствует о необходимости дальнейших исследований. Большинство ошибок можно исключить путем настройки конфигурации IBM Cognos BI, поскольку некоторые ошибки могут быть результатом узких мест в системе. В любом случае, прежде чем предпринимать какие-либо действия, обращайтесь к разделу Решение проблем и соответствующей документации по IBM Cognos. Выполните поиск по кодам ошибок, показанных на вкладке данных об ответах в дереве результатов проблемных запросов. Если вы не уверены в своих выводах, направьте PMR-запрос в службу IBM Cognos Support.

Если произошел сбой процесса BiBusTkServerMain и остался файл minidump (Windows) или core (UNIX/Linux), то вам следует немедленно связаться со службой IBM Cognos Support для внесения PMR-запроса. Вам потребуется предоставить план тестирования вместе с полной информацией о системной конфигурации.

Таким образом, результаты тестирования позволят оценить стабильность конкретной системы IBM Cognos BI в конкретных условиях. Необходимо обратить внимание на то, что данный план тестирования является лишь примером и ни в коем случае не может заменить привлечение квалифицированных специалистов IBM Cognos или партнеров для выполнения сложных тестов производительности и стабильности на месте. Свяжитесь с региональным представителем IBM Cognos для проведения тестирования на месте, если вам требуются убедительные и подтвержденные заявления относительно стабильности и производительности.

Решение проблем

В этом разделе приводятся некоторые наиболее распространенные сообщения об ошибках и советы по устранению причин таких ошибок. Безусловно, это не исчерпывающее руководство, а только краткий справочник. Для получения более подробной информации попробуйте найти ошибки, возвращаемые IBM Cognos BI, в базе документов Technotes, либо обращайтесь в службу IBM Support. Напоминаем, что для самого плана поддержка НЕ предоставляется.

Ошибки JMeter

  • Некоторые пункты меню в графическом пользовательском интерфейсе JMeter, например Open, недоступны (имеют серый цвет). В консоли появляется сообщение об исключительной ситуации (Java exception). Что делать: это проблема со стартовым сценарием (jmeter.bat/.sh), которую нужно исправить в сценарии. Если машина, на которой работает JMeter, имеет более одной среды JRE, то возможно, что приоритет из параметра PATH получает неправильная JRE. Именно так обстояло дело у автора данной статьи. Исправляется путем включения в сценарий команды set JM_LAUNCH=%JAVA_HOME%\bin\%JM_LAUNCH% перед вызовом JRE и установки JAVA_HOME в начале сценария.
  • JMeter не запускается.
    Что делать: убедитесь в том, что вы используете JRE версии не ниже 1.6.
  • Пользовательский интерфейс JMeter медленно реагирует либо не откликается вообще.
    Что делать: попробуйте запустить JMeter на более мощной системе или ограничьте количество потоков (пользователей) до 20–30.
  • В Result Tree Listener элементы плана тестирования не имеют запросов на выборку диаграмм или бинарных результатов.
    Что делать: проверьте, соответствует ли в плане параметр templocationзначению свойства Temporary object location в конфигурации IBM Cognos 10.

Ошибки IBM Cognos, наблюдаемые как страницы ошибок на вкладке с данными о результатах запроса при отображении в виде HTML:

  • Ошибка: DPR-ERR-2002 Unable to execute the request because there was no process available within the configured time limit. The server may be busy.
    Что делать: увеличьте время ожидания Dispatcher Queue.
  • Ошибка: RSV-ERR-0021 "The server cannot find a primary request with ID <someID>."
    Что делать: проверьте, не превышен ли лимит потоков вашего сервера приложений.

Ошибки плана, выделенные красным цветом в результатах Listener:

  • Прежде всего проверьте работоспособность отчета в браузере с использованием тех же учетных данных. Только в том случае, если он без проблем был исполнен 3 раза подряд, каждый раз в новом сеансе браузера, можно предположить, что причиной ошибки не является отчет в BI-системе.
  • Если через браузер отчет работает, отключите все элементы, кроме того, который содержит проблемный элемент. Это позволит сузить область поиска первопричины.
  • Если ошибка элемента повторяется и он содержит запрос значений, используйте Report Studio или Query Studio для дополнительной проверки прохождения значений. Найдите элемент данных, используемый для фильтра запроса. Затем определите Member Unique Name (MUN) требуемого запрашиваемого значения и скопируйте его в план. В качестве альтернативного варианта попробуйте выполнить отчет с использованием URL-адреса, передавая запрашиваемые значения как его параметры. В случае неудачи исправьте URL-адрес и вставьте в план корректный MUN.

Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Большие данные и аналитика
ArticleID=999283
ArticleTitle=Проверенные методики IBM Business Analytics: Пакет тестирования стабильности IBM Cognos BI с использованием инструмента JMeter
publish-date=03022015