在 python/django 中测试神秘的加载错误

Question

这与Configure Apache to recover from mod_python errors 有关，尽管我已经不再假设这与 mod_python 有任何关系。从本质上讲，我遇到了一个我无法始终如一地重现的问题，我想就所提出的解决方案是否可行以及尝试重现此问题的一些潜在方法获得一些反馈。

设置：使用 django 驱动的网站会在使用几天后开始抛出错误。它们总是ImportErrors 或ImproperlyConfigured 错误，这相当于同一件事，因为消息总是指定加载settings.py 文件中引用的某些模块时遇到问题。它通常不是同一类。我正在使用带有 8 个分叉子节点的 preforked apache，每当出现这个问题时，一个进程会被破坏，七个进程会很好。一旦中断，每个请求（在 apache conf 中使用 Debug On）在每次服务请求时都会显示相同的跟踪，即使失败的加载与特定请求无关。 httpd restart 总是让问题在短期内消失。

注意的问题：安装和更新是通过带有一些更新后脚本的 svn 执行的。一些.pyc 文件意外地被检入到存储库中。此外，该项目本身归一个用户所有（不是 apache，尽管 apache 对该项目有权限），并且有一个持久性插件最终以 root 身份获得后台。我把这些问题称为问题是因为无论我是否注意到这个错误，它们都是错误的，因此我已经修复了它们。该项目归apache所有，插件以apache为背景。所有.pyc 文件都在存储库之外，并且在服务器和插件停止时每次检出后都会强制重新编译它们。

我想知道的是

1. 这些配置灾难似乎是零星ImportErrors 的可能解释吗？
2. 如果我的代码中的其他地方仍然存在问题，我将如何最好地重现它？

至于2，我目前的做法是写一些压力测试，重复请求同一个页面，以执行公共代码路径。

顺便说一句，自修复以来，它已经运行了大约 2 天而没有发生任何事故，但在 1 到 10 天的时间间隔内观察到了问题。

Answer 1

“这些配置灾难是否可能是零星 ImportErrors 的可能解释”

是的。旧的.pyc 文件是头号灾难。

我们在 Windows 上开发，但在 Red Hat Linux 上运行生产。意外移动的 .pyc 文件对于调试来说绝对是个谜，因为 (1) 它通常会运行，并且 (2) 它具有原始源的 Windows 文件名，这使得回溯错误绝对毫无意义。我花了几个小时盯着日志——在 linux 上——想知道为什么文件是“C:\This\N\That”。

“如果我的代码中的其他地方仍然存在问题，我将如何最好地重现它？”

在重现错误之前，您应该尝试防止它们。

首先，创建单元测试来练习所有内容。

从 Django 的 tests.py testing 开始。然后将所有非 Django 组件扩展到 unittest。然后给自己写一个“run_tests”脚本来运行你拥有的每一个测试。定期运行它。每天是不够的。

其次，请确保您使用的是logging。沉重。

第三，将任何使用外部资源的东西包装在像这样的通用异常记录块中。

try:
    some_external_resource_processing()
except Exception, e:
    logger.exception( e )
    raise

这将帮助您查明外部资源的问题。由于权限或访问问题，文件和数据库通常是不良行为的根源。

此时，您已经避免了大量错误。如果您想运行循环负载测试，那也不是一个坏主意。为此使用单元测试。

class SomeLoadtest( unittest.TestCase ):
    def test_something( self ):
        self.connection = urllib2.urlopen( "localhost:8000/some/path" )
        results = self.connection.read()

这不是最好的做事方式，但它展示了一种方法。您可能想开始使用Selenium 来“从外部”测试网站，作为您单元测试的补充。