0

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

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

4

1 回答 1

0

从 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 的日志。需要一个过滤器才能从中获取有用的信息。在查看日志时，我们需要做两件事来从它们那里获取有关慢速请求的信息：

  1. 过滤请求时长：需要对超过 XXX 毫秒的请求进行排序
  2. 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来自长期保持活动连接，kudos 也这样做。我还排除了 mp4 电影，因为这些文件自然很大。当下载一部 500MB 的电影需要一些时间时，我们无需担心。有时我也看到它们带有 GET 参数，movie.mp4?logDownload=true&downloadType=view所以它们也被过滤了。

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

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

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

于 2020-11-03T13:59:30.720 回答