从 HCL Connections 对 Kudos Boards WebSphere 中的慢速 ajax 请求进行故障排除答案

【问题标题】：Troubleshoot slow ajax requests in Kudos Boards WebSphere from HCL Connections从 HCL Connections 对 Kudos Boards WebSphere 中的慢速 ajax 请求进行故障排除
【发布时间】：2020-11-03 13:59:30
【问题描述】：

我们仍然需要来自 ISW 的旧的基于 WebSphere 的 Kudos Boards。用户反映 ajax 操作，如设置截止日期或卡片中的负责人非常慢，有些甚至在完成之前中止。到目前为止，我在这里看不到为什么会发生这种情况的模式。它似乎与特定用户或客户无关。

如何解决这个问题？我想退后一步，先衡量一下处理请求需要多长时间。然后生成一个处理时间超过特定时间的所有请求的列表，比如说超过一秒。所以我们知道有多少用户受到了影响，并且他们之间可能存在一些共享的东西，比如网络慢的用户或类似的东西。

【问题讨论】：

标签： performance ibm-connections ibmhttpserver hcl-connections

【解决方案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"

分析测量数据

我们现在一天就有数百 MB 的日志。需要一个过滤器才能从中获取有用的信息。在查看日志时，我们需要做两件事来从它们那里获取有关慢速请求的信息：

按请求持续时间过滤：需要对超过 XXX 毫秒的请求进行排序
HCL Connections 和 Kudos Board 使用了一些非常古老的解决方法：它们保持 ajax 请求打开以获取有关服务器更新的信息。一种旧的 websockets 方式。这些请求只会向我们的慢日志发送误报。

为此，我编写了以下命令：

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 调用过滤掉所有在这里不感兴趣的请求：/push 来自长期保持活动连接，荣誉也这样做。我还排除了 mp4 电影，因为这些文件自然很大。当下载一部 500MB 的电影需要一些时间时，我们无需担心。有时我还看到它们带有 GET 参数，例如 movie.mp4?logDownload=true&downloadType=view，所以它们也被过滤掉了。

egrep '^[0-9]{4,}' 整理处理时间小于 4 位的请求，这基本上意味着 >= 1000 毫秒。由于我正在寻找严重的性能问题，因此这似乎是一个不错的起点。

sort -rnk 按持续时间降序排列我们的日志，因此我们在开头有最慢的条目。

wc -l $log 只是想知道我们这次收集了多少慢条目。现在可以使用less $log 查看它们。我们拥有超过 200 万条条目的大型访问日志已减少到 2k。

【讨论】：