Из IBM WebSphere Developer Technical Journal.

Введение

Что такое аналитика портала?

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

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

WebSphere Portal записывает информацию по использованию в специальный log-файл. Поскольку формат log-файла соответствует индустриальным стандартам ("NCSA Combined"), вы можете интегрировать данные по использованию портала с предпочитаемыми вами инструментальными средствами составления отчетов и анализа. В аналитику портала входят методы анализа по трендам, которые могут помочь вам предсказать требования к вашему порталу в будущем. Следовательно, оператор портала может предварительно планировать меры по адаптации к новым требованиям, чтобы избежать неожиданного удара после достижения максимальной загрузки.

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

Зачем беспокоиться об использовании портала?

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

О чем сообщают log-файлы

WebSphere Portal регистрирует следующие действия пользователя и делает их доступными для анализа:

• Управление страницей (создание, чтение, обновление, удаление страницы).
• Запросы пользователями отдельной страницы (включая содержащиеся на ней портлеты).
• Активность сессии (вход в систему, выход из системы, таймаут, неудачная попытка входа в систему).
• Действия по управлению пользователями (создание, чтение, обновление и удаление пользователей и групп).

Дополнительная информация о том, какие данные может создавать система ведения журналов WebSphere Portal, приведена в WebSphere Portal Information Center (см. раздел "Ресурсы").

Элементы аналитики портала

В недавнем отчете Patricia Seybold Group были определены следующие критерии для аналитики портала:

• Инструментарий
  Технологические платформы порталов должны собирать информацию по их использованию и производительности.

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

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

• Аналитика
  Иногда отчетов недостаточно и необходимо проведение анализа, для того чтобы понять поведение пользователей и оценить производительность.

Данная статья, посвященная инструментарию, кратко рассматривает способы составления отчетов на основе данных, выдаваемых WebSphere Portal.

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

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

Для чего не предназначена аналитика портала

Инструментарий аналитики портала не является заменой для других log-файлов, таких как аудит, производительность или системные события. Аудитория для log-файлов этих типов другая:

• Журналы для аудита обычно используются в защищенных средах, в которых регистрируются выполненные во время исполнения изменения конфигурации портала. Аудит, главным образом, является частью административной функции в WebSphere Portal. Аналитика портала, с другой стороны, концентрируется на той части портала, которую видят пользователи, а так же на том, как они используют портал.

• Журналы производительности используются для определения того, насколько хорошо конкретная часть всего портала выполняется в реальной рабочей среде. Они позволяют оператору определить, на что потратить ценные ресурсы портала (такие как CPU или оперативная память), придерживаясь установленных соглашений по уровню предоставляемого сервиса (Service Level Agreements - SLA).

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

Альтернативные решения

В данной статье не рассматриваются методики, использующие внешние службы ведения журналов, например, IBM SurfAid (сейчас принадлежит Coremetrics) или Google Analytics. Эти службы следят за активностью пользователя, помещая на страницу, отображаемую пользователю, определенную часть содержимого (обычно, некоторый встроенный JavaScript-сценарий или удаленное изображение), указывающего на провайдера сервиса. После визуализации страницы браузер извлекает эти элементы содержимого. Провайдер сервиса анализирует свои журналы доступа и предоставляет своим клиентам отчеты о том, к чему и когда обращались их пользователи. Такая методика называется также "Web beacon" (web-маяк), "Web bug" (web-жучок) или аналогично.

В начало

Использование аналитики портала

WebSphere Portal обеспечивает регистрацию аналитики, записывая события в специальный log-файл, аналогично регистрации для анализа отображения сервером статических страниц. Файл с аналитикой портала называется sa.log (sa означает site analytics - аналитика сайта) и обычно располагается в каталоге $WP_HOME/log/.

Каждая строка в sa.log представляет специфичное событие, которое было сгенерировано запросом к порталу. Один запрос (например, определенной страницы) может сгенерировать несколько строк, записываемых в sa.log. Вы можете настроить тип и размер журнала регистрации путем настройки соответствующего регистратора.

WebSphere Portal определяет следующие регистраторы аналитики сайта:

Для каждого взаимодействия пользователя с порталом соответствующий регистратор (если это сконфигурировано) создает новую запись в log-файле аналитики портала. Для каждого действия общий формат log-записи следует описанному выше определению. Отличие заключается в URI запроса, в котором записываются конкретные данные.

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

Конкретные данные для каждого регистратора помещаются в URI запроса либо как информация о пути, либо как параметры URI.

Использование регистраторов для записи событий

Давайте рассмотрим регистраторы более детально и исследуем формат соответствующего URI запроса.

SiteAnalyzerSessionLogger отвечает за запись активности пользователя, связанной с входом и выходом из системы. Когда пользователь входит в портал, URI запроса выглядит как /Command/Login, а пользовательский ID записывается как часть USER_ID log-записи. Если попытка входа в систему была неудачной, к URI запроса добавляется строка запроса ErrorCode=x (где x - это значение кода ошибки). Код состояния устанавливается в соответствующий HTTP-код состояния.

После выхода пользователя из портала (явно или по таймауту) создается log-запись с URI запроса /Command/Logout. Если причиной выхода является таймаут сессии, в URI запроса добавляется строка запроса Reason=SessionTimedOut.

Регистрация событий, связанных с управлением пользователями

Вы можете использовать SiteAnalyzerUserManagementLogger для записи любых событий, относящихся к управлению пользователями, которые выполняются через интерфейс администратора портала. При создании пользователя регистратор записывает событие в URI запроса как /Command/UserManagement/CreateUser. При удалении пользователя записывается /Command/UserManagement/DeleteUser.

Аналогичный механизм применяется для записи событий, связанных с созданием, изменением и удалением групп. Соответствующими URI являются /Command/UserManagement/CreateGroup, /Command/UserManagement/ModifyGroup и /Command/UserManagement/DeleteGroup.

Дальнейших подробностей о пользователе или группе, которые были субъектом операции, в настоящее время не записывается. Важно: регистрация событий не доступна в версиях до WebSphere Portal V6.

Регистрация событий, связанных со страницей

Когда страница отображается запросившему ее пользователю, SiteAnalyzerPageLogger создает соответствующую запись в log-файле. URI запроса начинается с /Page/, уникального ID объекта и названия страницы.

SiteAnalyzerPageLogger также записывает любые события, связанные с управлением страницей. URI запроса может быть /Command/Customizer/CreatePage, /Command/Customizer/EditPage или /Command/Customizer/DeletePage. Уникальный ID объекта и название страницы добавляются к URI запроса в качестве параметров строки запроса. Например:

/Command/Customizer/EditPage?Page=6_0_5RH_[CONTENT_NODE:6001]&PageName=Products

В этом примере была изменена страница с ID объекта 6_0_5RH и с именем Products.

Регистрация событий, связанных с портлетами

Если сконфигурирован SiteAnalyzerPortletLogger, он создает log-запись для каждого визуализируемого портлета, независимо от того, на какой странице тот находится.

URI запроса log-записи начинается с /Portlet/. Добавляется уникальный ID объекта визуализируемого портлета и его название. Строка запроса содержит уникальный ID объекта вместе с текущими режимом портлета {View, Edit, Configure, Help} и состоянием {Normal, Minimized, Maximized}.

Если включены оба регистратора (SiteAnalyzerPageLogger и SiteAnalyzerPortletLogger), визуализация одной страницы может привести к нескольким log-записям в файле sa.log (одна строка для страницы и одна строка для каждого портлета, находящегося на этой странице).

Регистрация действий с портлетом

SiteAnalyzerPortletActionLogger не активируется общей инфраструктурой событий в WebSphere Portal. Он записывает строки при ручном его вызове, и URI запроса начинается с /PortletAction/.

Регистрация ошибок

Если при визуализации страницы или портлета возникает ошибка, SiteAnalyzerErrorLogger создает соответствующую запись в log-файле аналитики. Это не замена log-файлов системных ошибок (wps_*.log); он позволяет вам записывать ошибки с точки зрения бизнес-логики, например, количество ошибочных портлетов за определенный промежуток времени.

Если есть ошибки, соответствующая log-запись начинается с /Error/Portlet или /Error/Page.

Регистратор событий, относящихся к приложению

Этот регистратор зарезервирован для использования в будущем. Его назначение - разрешить портлетам вносить информацию в log-файл аналитики сайта. Однако на момент написания данной статьи использование этого регистратора еще не поддерживается.

Если регистратор записывает чего-нибудь, URI запроса будет начинаться с /ApplicationAction/.

Исследование формата log-файла

Формат log-записей соответствует формату NCSA Combined log. Используя расширенную форму Бэкуса-Наура (Extended Backus-Naur Form - EBNF), его можно формально определить следующим образом:

STRING = ? любой печатный символ, за исключением знака вопроса ?;
HOST, CLIENT_ID, USER_ID = STRING;
HYPHEN = "-";
QUOTE = """;
SIGN = "+" | "-";
SPACE = " ";
TWODIGITHOURS = "00".."23";
MINUTES = "0..59";
DAY = "00..31";
MONTH = "01..12";
SLASH = "/";
COLON = ":";
RFC822TIMEZONE = SIGN SPACE TWODIGITHOURS SPACE MINUTES;
TIMESTAMP = DAY SLASH MONTH SLASH YEAR COLON HOURS COLON MINUTES COLON SECONDS SPACE 
   RFC822TIMEZONE;
PORT = 0..65535;
URI = "http" | "https" + COLON + SLASH + SLASH + HOST + PORT + STRING;
STATUS_CODE = NUMBER ? должен быть легальным HTTP-кодом состояния ?;
BYTES = NUMBER;
REFERER = URI;
REQUEST = "GET" | "POST" | "PUT" | "DELETE" URI SPACE "HTTP/1.0" | "HTTP/1.1";
SA_LINE = HOST SPACE CLIENT-ID|HYPHEN SPACE USER_ID|HYPHEN SPACE "[" TIMESTAMP"]" 
   SPACE QUOTE REQUEST_URI QUOTE STATUS_CODE SPACE BYTES SPACE REFERER SPACE QUOTE 
   USER_AGENT QUOTE SPACE QUOTE COOKIES QUOTE;

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

Корреляционная информация

Наряду с желанием знать, какие страницы запрашиваются пользователями, может также возникнуть необходимость узнать взаимоотношения между запросами. Поскольку HTTP является протоколом, не сохраняющим состояния, не существует внутренней информации о странице, которую просматривал пользователь перед текущей страницей. Эта проблема обычно решается использованием пользовательской сессии, и именно этот способ применяется в WebSphere Portal и WebSphere Application Server.

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

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

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

Примеры

Регистрация запросов страницы

Когда пользователь запрашивает страницу (и PageLogger включен), WebSphere Portal создает log-запись для этой страницы:

localhost - wpsadmin [15/Jun/2006:23:42:10 +0200] "GET /Page/6_0_4D_[CONTENT_NODE:
141]/Welcome HTTP/1.1" 200 -1 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.8.0.4) Gecko/20060508 (CK-IBM) Firefox/1.5.0.4" "JSESSIONID=
0000c9fiQ6Q14XUbsp3QFQHFkq9:-1"

Вы можете извлечь следующие данные из log-записи:

• Запрос был сделан с localhost.
• Аутентифицированным пользователем для данного запроса был wpsadmin (краткое имя пользователя).
• Обработка запроса была закончена в 15/Jun/2006:23:42:10, GMT +0200.
• Была запрошена страница с заголовком "Welcome".
• Запрос был успешным (HTTP-код ответа равен 200).
• Размер возвращенной разметки неизвестен регистратору (-1).
• Запрос был сделан браузером, идентифицирующим себя как "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 (CK-IBM) Firefox/1.5.0.4", что на самом деле указывает на Firefox 1.5.0.4, выполняющемся на платформе Windows® XP.
• Запрос был сделан внутри сессии с идентификатором "0000c9fiQ6Q14 XUbsp3QFQHFkq9".

Регистрация запросов страницы и портлета

Когда пользователь запрашивает страницу, а PageLogger и PortletLogger включены, log-записи создаются для страницы и каждого портлета этой страницы. Первая log-запись и содержащаяся в ней информация будет аналогична упомянутой выше:

localhost - wpsadmin [15/Jun/2006:23:42:10 +0200] "GET /Page/6_0_4D_[CONTENT_NODE:
141]/Welcome HTTP/1.1" 200 -1 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; 
en-US; rv:1.8.0.4) Gecko/20060508 (CK-IBM) Firefox/1.5.0.4" "JSESSIONID=
0000c9fiQ6Q14XUbsp3QFQHFkq9:-1"

Поскольку теперь включен PortletLogger, для каждого портлета, содержащегося на этой странице, создается дополнительная запись, например:

localhost - wpsadmin [15/Jun/2006:23:42:16 +0200] "GET /Portlet/5_0_49_[PORTLET_
ENTITY:137]/Welcome_to_WebSphere_Portal?PortletPID=5_0_49_[PORTLET_ENTITY:137]&Portlet
Mode=View&PortletState=Normal HTTP/1.1" 200 -1 "http://localhost/Page/6_0_4D_[CONTENT_
NODE:141]/Welcome" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4)
Gecko/20060508 (CK-IBM) Firefox/1.5.0.4" "JSESSIONID=0000c9fiQ6Q14XUbsp3QFQHFkq9:-1"

Дополнительной информацией в этой строке является:

• Был отображен портлет с заголовком "Welcome to WebSphere Portal" (/Portlet/ 5_0_49_[PORTLET_ENTITY:137]/Welcome_to_WebSphere_Portal).
• Он был отображен в режиме View, и его состояние было установлено в Normal (не minimized, maximized или solo - PortletMode=View&PortletState=Normal).
• Он размещен на станице с названием "Welcome" (referrer, http://localhost/Page/6_0_4D_[CONTENT_NODE:141]/Welcome).

Сначала регистрация информации о том, какой портлет был запрошен, кажется излишней; статическая конфигурация портала должна точно рассказать, какие портлеты развернуты для определенной страницы. Однако каждый пользователь с ролью Editor может удалить или заменить портлеты по желанию. Регистрация как страницы, так и портлетов позволит вам определить, какие портлеты запросил пользователь.

Аналогично, PortletLogger записывает страницу, в которую включен портлет, в поле referrer. Если PageLogger отключен, это поле позволит вам определить, какая страница отобразила портлет.

Информация, которую можно извлечь из log-записи

Основываясь на этих данных, пакет аналитики может создать следующие отчеты:

• Хосты и домены пользователей, посещающих портал (подсчитывая и группируя элементы HOST).
• Различные входы в систему, соответствующие аутентифицированным пользователям (подсчитывая и группируя элементы USER_ID).
• Детальная информация о роботах и браузерах (подсчитывая и группируя элементы USER_AGENT).
• Запрошенные, но не найденные страницы (STATUS_CODE).
• Поисковые механизмы, ключевые фразы и ключевые слова (REFERER).
• Различные операционные системы, информация о которых передается браузером (USER_AGENT).
• Страница, с которой пришел пользователь (REFERER).
• Входной и выходной URL (самая первая и самая последняя страницы, запрошенные внутри уникальной сессии).

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

В начало

Составление отчетов с использованием инструментальных средств с открытым исходным кодом

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

Знакомство с примером

Пример создает один простой отчет, называемый "This Month's Top Pages" (самые популярные страницы в этом месяце). Этот отчет должен предоставить график страниц, запрошенных за определенный промежуток времени. Он будет показывать название страницы и количество обращений (число запросов этой страницы).

Включение инструментария

Начнем с разрешения соответствующего инструментария в WebSphere Portal:

• Разрешите регистратор, установив следующие значения в консоли администратора WebSphere Application Server.

  SiteAnalyzerPageLogger.isLogging=true
SiteAnalyzerPortletLogger.isLogging=true

  Обычно эти настройки уже имеются; просто их надо установить в новые значения (подробная информация по этой процедуре приведена в теме "Настройка свойств конфигурации" в Portal WebSphere V6 Information Center).

• Перезапустите WebSphere Portal.
• Сделайте несколько запросов портала и затем проверьте, что файл sa.log содержит новые записи.

Установка и конфигурирование AWStats

AWStats поставляется с подробной информацией по его установке. Для нашего примера мы будем использовать только автономный (offline) анализ. Следовательно, достаточно:

1. Загрузить AWStats.

2. Разархивировать пакет в каталог.

3. Сконфигурировать сайт согласно документации. Например, создайте awstats.localhost.conf (localhost - это название сайта) и измените следующие выражения:

   LogFile="C:\Program Files\IBM\Portal51UTE\PortalServer\log\sa.log" LogFormat=1 LogSeparator=" " SiteDomain="localhost" DNSLookup=1 AllowToUpdateStatsFromBrowser=0

   
   

4. Создайте начальную базу данных для статистики:

   perl awstats.pl -config=localhost -update

5. Создайте общий отчет, как показано на рисунке 1:

   perl awstats.pl -config=localhost -output -staticlinks > awstats.localhost.html

   
   
   Рисунок 1. Общий отчет, сгенерированный AWStats
   
   
   

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

Чтобы увидеть, как различные отчеты связаны с различными схемами запросов, вы создадите набор тестовых страниц, тестовых пользователей и тестовых запросов. Затем вы сможете увидеть, как AWStats анализирует и выдает отчеты для различных схем запросов.

Создание тестовой иерархии страниц

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

Для создания запросов в этом примере мы будем использовать программу Apache JMeter. В целях упрощения создайте иерархию предопределенных страниц портала, вызываемых при помощи JMeter. Структура страниц примера похожа на часть структуры домашней страницы ibm.com:

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

Присвойте каждой странице контекст отображения URI. Это немного облегчит настройку JMeter.

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

Кроме показа запросов различных страниц примерный отчет должен также показывать запросы по различным аутентифицированным пользователям. XMLAccess поддерживает создание пользователей и групп, если соединение с пользовательским реестром настроено на права чтение/запись. Архив кода в загрузочном файле содержит XMLAccess-сценарий (createPortalAnalyticsTestUsers.xml), который создает несколько тестовых пользователей и группу, их содержащую.

Сценарий, создающий иерархию страниц примера, предполагает, что существует группа "Portal Analytics Test-Users". Сценарий createPortalAnalyticsTestUsers.xml также создает эту группу.

Установка и настройка JMeter

JMeter - это простая программа тестирования нагрузки из проекта Apache Jakarta. Это чистокровная Java-программа, которая тестирует производительность сервера, используя различные протоколы. В данном примере мы используем ее HTTP-соединение для создания последовательности запросов к порталу. Затем мы можем использовать (вручную) корреляцию между выполненными программой JMeter запросами и результатами, записанными аналитикой портала в файл sa.log.

Примеры данной статьи были созданы при помощи программы JMeter 2.2, которую вы можете загрузить. После выполнения всех предварительных требований вы можете запустить ее из подкаталога bin каталога JMeter. Главное окно программы будет выглядеть примерно так, как показано на рисунке 3.

Начальная настройка, в основном, следует указаниям руководства пользователя JMeter. Вы создаете план тестирования для входа в систему с одним из наших тестовых пользователей (analyticsTest001 .. analyticsTest009), а затем запрашиваете домашнюю страницу. Не тратя время на раздумья, следующие запросы обращаются к страницам product, services, support и account. Итерация завершается без выхода из системы.

Не слишком углубляясь в подробности конфигурирования JMeter, приведем главные конфигурационные элементы, использующиеся для проведения тестирования:

• Thread Group "Analytics Test Users" выполняется с 10 пользователями (потоками).
• HTTP Request Defaults установлен на http://localhost:9081.
• HTTP Cookie Manager используется для отслеживания куки, но очищает их для каждой итерации.
• HTTP Header Manager посылает пользовательский заголовок User-Agent. Вы можете использовать эту методику в рабочей среде, чтобы отличить искусственные JMeter-запросы от запросов реальных пользователей.
• Пять HTTP-запросов таковы:
  1. Вход в систему. Мы используем для входа в систему приведенный ниже URL и передаем случайно выбранный пользовательский ID.

     /wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid= <your user id>&password=<your password>

  2. /analytics/home
  3. /analytics/products
  4. /analytics/services
  5. /analytics/support
  6. /analytics/account
• Наконец, View Results Tree показывает результаты плана тестирования.

Архив загрузочного файла содержит пример плана тестирования для JMeter (PortalAnalyticsExample.jmx), показанный на рисунке 4.

Выполнение теста

Выполнить тест легко. После настройки всех частей (тестовых пользователей, иерархии страниц и плана тестирования) вызовите тест, выбрав Run => Start программе JMeter. Программа создает десять потоков, каждый из которых моделирует отдельного тестового пользователя. Каждый пользователь входит в портал и выбирает определенную последовательность страниц.

Результаты

После завершения выполнения плана вы можете вызвать AWStats для обновления отчетов (см. раздел "Ресурсы"):

perl awstats.pl -config=localhost -output -staticlinks > awstats.localhost.html

Результаты, изображенные на рисунке 5, показывают, что самой популярной страницей для нашего плана тестирования является домашняя страница. Однако отображается 20 обращений. Разве мы не имитировали только 10 пользователей с одной итерацией для каждого? Это не удивительно, если вы подумаете о способе работы WebSphere Portal и J2EE™. Первым выполненным нами запросом является запрос на вход в систему. Если он успешен, WebSphere Portal отображает самую первую страницу, на просмотр которой имеет права пользователь. В данном случае, если ниже "My Portal" нет ничего кроме нашей тестовой иерархии, первой страницей является домашняя страница. Но мы опять запрашиваем домашнюю страницу в следующем вызове после входа в портал. Следовательно, мы получаем удвоенное число обращений к домашней странице.

Самым популярным портлетом является "Information Portlet". Опять же, здесь нет ничего удивительного, поскольку мы имеем только один портлет в нашем одном шаблоне страницы.

В реальном сценарии этот отчет, конечно же, выглядел бы намного сложнее. Однако небольшая и простая настройка в этом примере дает четкое представление о работе аналитики портала.

В начало

Настройка конфигурационных параметров в WebSphere Portal V5.1

Конфигурирование WebSphere Portal V5.1 для аналитики портала немного отличается от процедуры настройки WebSphere Portal V6. Основным отличием является то, что в WebSphere Portal V5.1 все конфигурационные настройки производятся через файлы свойств, в то время как WebSphere Portal V6 управляет своей конфигурацией при помощи функциональности Resource Environment Provider сервера WebSphere Application Server V6.

Чтобы разрешить инструментарий аналитики в WebSphere Portal V5.1, включите регистратор в <wp_home>/shared/app/config/services/SiteAnalyzerLogService.properties, установив:

SiteAnalyzerPageLogger.isLogging=true
SiteAnalyzerPortletLogger.isLogging=true

Обычно эти строки уже имеются, просто они закомментированы. В этом случае достаточно просто удалить символы комментариев. Все остальные элементы аналогичны элементам для WebSphere Portal V6.

В начало

Заключение

Log-файл аналитики WebSphere Portal предоставляет все необходимые данные для аналитики портала. Хотя записанные URL не являются реальными, запрашиваемыми URL, они все равно предоставляют важную информацию для определения того, какие страницы просматривали пользователи портала.

В данной статье были рассмотрены данные, собираемые WebSphere Portal в log-файле аналитики, а также было показано, как использовать эти данные с пакетом анализа Web-сайтов AWStats с открытым исходным кодом.

В начало

Загрузка

Информация о методах загрузки

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи "IBM WebSphere Developer Technical Journal: Using portal analytics with open-source reporting tools".
  
  
• NCSA Combined Log Format.
  
  
• Тема "Анализ сайтов" в WebSphere Portal V5 Information Center.
  
  
• Тема "Анализ сайтов" в WebSphere Portal V6 Information Center.
  
  
• IBM WebSphere Portal 5.1.0.1. Как IBM Portal соответствует нашей оценочной интегрированной среде пользовательских порталов, Kramer, Mitchell I, Patricia Seybold Group
  
  
• Slashdot-эффект.
  
  
• Служба аудита, WebSphere Portal 5.1 Information Center.
  
  
• Измерение Web-трафика, часть 1.
  
  
• Измерение Web-трафика, часть 2.
  
  
• EBNF, ISO Standard ISO/IEC 14977:1996(E), окончательный проект.
  
  
• "Интерфейс HttpSession", документация по J2EE 1.4 API.
  
  
• AWStats.
  
  
• Apache JMeter.
  
  
• Создание плана тестирования Web.
  
  
• Аналитика использования портала: Основные инструментальные средства в битве против Empty Portal, Хаддад, Роберт.
  
  
• IBM Tivoli Web Site Analyzer V4.5 Information Center.
  
  
• Анализ Web-журналов с AWStats, часть 1, Карлос, Син.
  
  
• Анализ Web-журналов с AWStats, часть 2, Карлос, Син.
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Использование аналитики портала
• Составление отчетов с использованием инструментальных средств с открытым исходным кодом
• Настройка конфигурационных параметров в WebSphere Portal V5.1
• Заключение
• Загрузка
• Ресурсы
• Об авторах
• Комментарии