2017-03-22 29 views
1

我有一个简单的扭曲应用程序,我使用systemd服务运行,执行脚本,随后执行.tac文件。使用双绞线和系统处理缓存预热

应用程序的结构为JSON RPC端点(fastjsonrpc),内置到t.w.r.Resource,这在t.w.s.Site,并担任t.a.i.TCPServer,整个事情包装成一个t.a.Application。这工作正常。

我遇到麻烦的地方是当我尝试在启动时预热缓存。这个预热过程非常慢(约300秒),并使systemd超时并终止进程。增加超时并不是一个真正可行的选择,因为我不希望这会阻止系统启动。

在Apache和wsgi中,在Flask上运行的单独堆栈中使用类似的代码。该服务器自动启动,让系统继续运行,同时需要花费时间建立缓存。这种行为对我来说很好。

我已经打过电话使用twrResource的设置功能中的以下的预热功能:

reactor.callLater(1, ep.warmup, None) 

我还没使用这种从systemd内进行审判,并从twistd来一直在测试它直接在命令行上。服务器按预期工作,但不再响应SIGINT(^ C)。删除callLater是让服务器响应SIGINT所需要的一切。

如果直接调用暖机功能(而不是通过callLater,即等待暖机完成时systemd放弃的安排),则生成的服务器也会继续响应SIGINT。

  1. 有没有更好的方法来处理这种长时间运行的热身代码?
  2. 为什么扭转/反应堆不响应SIGINT?我在这里错过了什么吗?

回答

0

Twisted是单线程的事情。这听起来像你的“缓存预热”代码阻止了300秒的反应堆。一个简单的方法来解决这个问题将使用deferToThread让它运行没有阻止反应堆。

+0

我没有问题,它阻止了300秒的反应堆,但我需要反应堆正常后响应。反应堆正常工作,否则不再响应SIGINT/SIGTERM,需要停止SIGKILL。 deferToThread不太可能适用于我,因为我的缓存是非常复杂的python对象网络。 –

+0

或者,您可以重写“热身”程序以返回延迟,从而定期对反应堆进行控制。我不确定这可能与您看到的信号行为有关,但这是更好的方法。一种方法是仅使用@inlineCallbacks并在每次循环迭代中使用“yield”(如果它是循环的话)。 – meejah