我正在使用 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 时间是 125 毫秒，所以即使消息是同步发送的，600 毫秒仍然显得异常大。有没有我可以更改的配置以加快速度？
设置文件:
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,
},
}
}
=== 编辑 ===
感谢 Filip Dupanović 指出 threading+ 协议(protocol)。可悲的是，由于在引导 worker 时线程被复制，他们在 gunicorn 中对我不起作用。我通过在 gunicorn 配置文件中添加一个 post_fork 钩子(Hook)来修复它，如下所示:
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.")
Obv 这是一个 hack，虽然它对我有用，但我不知道它是否适用于其他任何地方。
最佳答案
如果您使用托管的 Sentry 服务，您可能会受益于切换到 Raven 完全支持的 threaded+http 传输。看看Raven's documentation关于如何在服务名称中正确配置传输。
您可能还想尝试切换到其他一些专门的并发传输或 UDP 协议(protocol)。虽然您无法将 ICMP 请求延迟与 TCP 进行比较，但是增加的开销非常可怕并且可以解决，所以不要害怕!
关于python - Django Raven 非常慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19003550/