我正在使用raven和getsentry在django中记录消息,但是该记录似乎延迟了代码的执行。例如:

# ...view code
tic = datetime.datetime.now()
logging.warning('foo warning')
toc = datetime.datetime.now()
print "log time %s, %s, %s" % (tic, toc, (toc - tic).total_seconds())
# more view code...

给出输出:
log time 2013-09-25 12:03:56.541091, 2013-09-25 12:03:57.139420, 0.598329

也就是说,在这种情况下,它会将代码执行延迟600毫秒。这是可以预期的吗?我以为该消息将在单独的线程中异步发送,因此主代码不会被延迟。另外,我对app.getsentry.com的ping时间是125ms,因此即使消息同步发送,600ms仍然看起来非常大。我可以更改一些配置以使操作更快吗?

设置文件:
LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'handlers': {
        'sentry': {
            'level': 'INFO',
            'class': 'raven.contrib.django.raven_compat.handlers.SentryHandler',
        },
    },
    'loggers': {
        '': {
            'handlers': ['sentry'],
            'level': 'INFO',
            'propagate': True,
        },
    }
}

===编辑===

感谢FilipDupanović指出了threading +协议(protocol)。可悲的是,由于在引导工作人员时复制了线程,因此它们在我的工作中没有为我服务。我通过在gunicorn配置文件中添加post_fork钩来修复它,如下所示:
import logging
from raven.contrib.django.handlers import SentryHandler
from raven.transport.threaded import ThreadedHTTPTransport


def post_fork(server, worker):
    LOG = logging.getLogger()
    for handler in LOG.handlers:
        if isinstance(handler, SentryHandler):
            for url, transport in handler.client._registry._transports.items():
                if isinstance(transport, ThreadedHTTPTransport):
                    if hasattr(transport, '_worker'):
                        server.log.info("deleting sentry thread worker attribute")
                        delattr(transport, '_worker')
                    else:
                        server.log.info("sentry thread worker not present, nothing to do.")

观察这是一个hack,虽然对我有用,但我不知道它是否可以在其他地方使用。

最佳答案

如果您使用托管的Sentry服务,则可能会受益于切换到Raven完全支持的threaded+http传输。查看Raven's documentation,了解如何在服务名称中正确配置传输。

您可能还想尝试切换到其他一些专门的并发传输或UDP协议(protocol)。尽管您无法将ICMP请求延迟与TCP进行比较,是的,增加的开销简直太可怕了,可以解决,所以请不要担心!

10-07 17:51