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

Question

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

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

Answer 1

Сбор журналов продолжительности запросов из 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_11_03.log | egrep '^[0-9]{4,}' | sort -rnk1 > $log; wc -l $log

Первый egrep call отфильтровывает все запросы, которые здесь не интересны: /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 КБ.