将Zope2实例中长时间运行的请求的堆栈跟踪输出到日志文件
项目描述
简介
此产品将Zope2实例中长时间运行的请求的堆栈跟踪输出到日志文件。如果一个请求的执行时间超过配置的超时时间，则它的堆栈跟踪将定期输出到日志文件。
由Leonardo Rochael Almeida编写，得益于Nexedi慷慨捐赠的开发者时间，并得到Sébastien Robin和Julien Muchembled的设计建议。
安装
Buildout安装
将“Products.LongRequestLogger”添加到定义您的Zope实例的部分的egg列表中。
配置
将您的zope.conf中的“<product-config LongRequestLogger>”部分添加（或更改）为以下内容
<product-config LongRequestLogger>
logfile $INSTANCE/log/longrequest.log0.log
timeout 4
interval 2
</product-config>
以下变量被识别
“logfile”：这是一个必需变量。其缺失意味着LongRequestLogger对发布机的猴子补丁将不会应用。它应指向您希望长时间请求被记录的文件。
“timeout”：长请求开始被记录的秒数。接受浮点数，默认为2。
“interval”：长请求超过上述“timeout”后，其堆栈跟踪将被记录的频率。默认为1，接受浮点数。
结果解释
在查看结果时，注意以下几点关于Zope2应用程序和线程行为的事实非常重要
每个线程一次只处理一个请求。
慢请求通常会有一个常见的顶部部分和一个可变底部部分的回溯。请求中减速的原因的关键在于两者的限制。
如果您处于紧急情况，不想解析文件以对最慢的URL进行排名调查，请选择一个秒数，它是您的间隔加上超时的倍数，并用grep搜索它。对于默认的超时和间隔设置，您将找到4秒、6秒、8秒的日志条目，因此您可以执行以下grep操作
$ grep -n "Running for 8" longrequest.log
然后根据哪些URL出现得更频繁做出决定。然后您可以打开日志文件，转到报告的行号，通过在文件中上下搜索相同的线程ID（报告行中的“Thread”后面的数字）来导航回溯。然后分析单个请求的回溯之间的差异，以了解这个特定的请求正在做什么以及为什么它会减慢。
通过为多个类似请求执行此操作，您将能够提出优化或缓存策略。
变更日志
2.1.0 (2017-09-11)
记录在转储请求时引发的异常。不可打印的请求导致监视线程死亡，从而导致ZPublisher包装器中的EPIPE错误。
如果未更改，切勿重复请求信息、回溯或SQL查询。
2.0.0 (2015-11-04)
配置现在通过zope.conf中的“product-config”部分完成，而不是环境变量。
记录ZMySQLDA执行的查询。
如果与前一个堆栈跟踪相同，则合并堆栈跟踪输出到单行。
删除通过更改环境变量在运行时更改行为的不太使用的机制，例如将日志重定向到不同的文件名、停止日志记录或更改超时。日志轮换仍然正常工作。
停止为每个请求创建和结束一个额外的线程。相反，在启动时启动一个单一的监视线程。
放弃与Python < 2.6的兼容性。
1.1.0 (2012-09-10)
对代码的可读性进行了一些重构。
使用os.pipe()对和select.select()代替threading.Condition来在监视器应停止跟踪原始线程时发出信号。这避免了在某些VMware安装中的一些性能瓶颈，这些安装似乎在特定条件下锁的性能不好。
将日志机制与Zope的信号处理和ZConfig的轮转文件处理程序集成，以便USR2信号将导致长请求日志类似于访问和事件日志被重新打开。
1.0.0 (2010-10-28)
首次发布
下载文件
下载适用于您的平台的文件。如果您不确定选择哪个，请了解更多关于安装包的信息。