Устранение неполадок медленных запросов ajax в Kudos Boards WebSphere из подключений HCL

Нам все еще нужны старые доски Kudos Boards на базе WebSphere от ISW. Пользователи сообщали, что операции ajax, такие как установка сроков или ответственных лиц в карточке, очень медленные, а некоторые даже прерываются до завершения. До сих пор я не вижу здесь закономерности, почему это происходит. Кажется, это не связано с конкретным пользователем или клиентом.

Как это можно было устранить? Я хотел бы сделать один шаг назад и сначала измерить, сколько времени занимает обработка запросов. Затем создается список всех запросов, для обработки которых потребовалось больше определенного времени, скажем, более одной секунды. Итак, мы знаем, сколько пользователей пострадали от этого, и, возможно, между ними есть общие вещи, например, пользователи в медленной сети или что-то в этом роде.


performance ibmhttpserver ibm-connections hcl-connections
person Lion    schedule 03.11.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Сбор журналов продолжительности запросов из IHS

Модуль Apache mod_log_config позволяет регистрировать определенные свойства. Интересно %T:

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

Используя формат %{UNIT}T, он может отображаться в микросекундах вместо секунд, что лучше для анализа позже. Поэтому я расширил формат общего журнала, чтобы сначала записать время обработки в conf/httpd.conf:

LogFormat "%{ms}T %h %l %u %t \"%r\" %>s %b" common

Еще одна хорошая идея - добавить также User-Agent, который дает некоторую информацию о типе клиента:

LogFormat "%{ms}T %h %l %u %t \"%r\" %>s %b \"%{User-Agent}i\"" common

Сначала проверьте файл конфигурации, чтобы убедиться, что мы ничего не сломали:

/opt/IBM/HTTPServer #./bin/apachectl -t
Syntax OK

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

./bin/apachectl -k graceful

Все новые запросы регистрируются с продолжительностью в мс следующим образом:

100007 1.2.3.4 - - [03/Nov/2020:14:29:52 +0100] "POST /push/form/comet/connect HTTP/1.1" 200 96 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0"

Анализ измеренных данных

Теперь у нас есть несколько сотен МБ журналов за один день. Чтобы получить от них полезную информацию, нужен фильтр. При просмотре журналов нам нужно сделать две вещи, чтобы получить от них информацию о медленных запросах:

  1. Фильтр по продолжительности запроса: запросы, которые быстрее, чем XXX мс, должны быть отсортированы
  2. HCL Connections и Kudos Board используют некоторые очень старые обходные пути: они оставляют запросы ajax открытыми, чтобы получать информацию об обновлениях сервера. Старый способ использования веб-сокетов. Эти запросы просто спамят нашим медленным журналом ложными срабатываниями.

Для этого я написал следующую команду:

log=/tmp/access-slow.log; egrep -i -v "(POST /(push|files)/|GET /(kudosboards/updates|api-boards)/|\.mp4(\?[A-Za-z0-9_\-=&]+)? HTTP)" logs/access_2020/push03.log | egrep '^[0-9]{4,}' | sort -rnk1 > $log; wc -l $log

Первый вызов egrep отфильтровывает все запросы, которые здесь не интересны: /push - это соединения с длительным сохранением активности, это тоже делается с уважением. Я также исключил фильмы в формате mp4, потому что эти файлы естественно большие. Когда загрузка фильма размером 500 МБ занимает некоторое время, нам не о чем беспокоиться. Иногда я также видел их с параметрами GET, такими как movie.mp4?logDownload=true&downloadType=view, поэтому они тоже были отфильтрованы.

egrep '^[0-9]{4,}' сортирует запросы, время обработки которых меньше 4 цифр, что в основном означает ›= 1000 мс. Поскольку я ищу серьезные проблемы с производительностью, это хороший момент для начала.

sort -rnk упорядочивает наши журналы по убыванию продолжительности, поэтому в начале у нас самые медленные записи.

wc -l $log просто чтобы узнать, сколько медленных записей мы собрали на этот раз. Теперь их можно было просматривать с less $log. Наш большой журнал доступа с более чем 2 миллионами записей был уменьшен до 2 КБ.

person Lion    schedule 03.11.2020