代码之家  ›  专栏  ›  技术社区  ›  Aiden Bell

mod_wsgi/python正在优化吗?

  •  2
  • Aiden Bell  · 技术社区  · 16 年前

    我一直在努力寻找我的mod wsgi/python web应用程序的奇怪问题。我有一个应用程序处理程序,它创建一个对象并调用一个方法:

    def my_method(self, file):
        self.sapi.write("In my method for %d time"%self.mmcount)
        self.mmcount += 1
    
        # ... open file (absolute path to file), extract list of files inside
        # ... exit if file contains no path/file strings
        for f in extracted_files:
            self.num_files_found += 1
            self.my_method(f)
    

    在这一切的开始和结束,我写道

    obj.num_files_found
    

    到浏览器。

    所以这是一个递归函数,它沿着文件中的文件引用树向下移动。打印文件中的任何引用,然后打开并检查这些引用,依此类推,直到所有文件都是不包含文件的叶节点。为什么我这么做并不重要…这更像是一个学究式的例子。

    您将期望输出具有确定性

    Files found: 0
    In my method for the 0 time
    In my method for the 1 time
    In my method for the 2 time
    In my method for the 3 time
    ...
    In my method for the n time
    Files found: 128
    

    对于前几个请求,它是预期的。 那么只要刷新,我就可以得到以下内容

    Files found: 0
    In my method for the 0 time
    Files found: 128
    

    即使我知道,从以前的刷新和没有代码/文件修改,它需要 n 枚举128个文件的次数。

    那么问题是: mod_wsgi/python是否包含会停止执行的内部优化?它是否猜测输出是确定性的和缓存的?

    注意,在按预期刷新时,远程端口每次增加一个…当使用短输出时,远程端口的增量会急剧增加。不过,可能与此无关。

    我是巨蟒的新手,温柔点

    解决了的

    谁知道它是什么,但撕掉了Apache、mod_python、mod_wsgi和几乎所有与HTTP相关的东西,重新安装解决了这个问题。有件事是 相当破碎 但现在看来还行:)

    3 回复  |  直到 15 年前
        1
  •  1
  •   S.Lott    16 年前

    “mod_wsgi/python是否包括会停止执行的内部优化?它是否猜测输出是确定性的和缓存的?”

    不。

    问题是(通常)在程序中的某个地方有一个全局变量,它没有按照您希望的方式进行重置。

    有时这是无意的,因为Python检查本地命名空间和全局命名空间中的变量。

    您可以——无意中——拥有一个依赖于某个全局变量的函数。我敢打赌。

    您可能会看到许多mod wsgi守护进程,每个进程都有一个全局变量问题。每个守护进程的第一个请求工作正常。然后,全局变量处于阻止工作发生的状态。[文件保持打开状态,顶级目录变量被覆盖,谁知道?]

    在前几个守护进程之后,所有守护进程都停留在“另一个”模式中,在该模式中,它们报告答案而不做真正的工作。

        2
  •  3
  •   Graham Dumpleton    15 年前

    Apache/mod_wsgi可以在两种多进程/多线程配置中运行,这可能会触发代码,代码是在假设它在单个进程中运行的情况下编写的,而该进程可能是单线程的。有关不同配置可能性以及共享数据的含义的讨论,请参见:

    http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

        3
  •  1
  •   Aiden Bell    16 年前

    似乎必须破坏python/mod wsgi安装。我从没见过这么奇怪的虫子。 返回旁边的跟踪:

    self.sapi.write("Returning at line 22 for call %d"%self.times_called)
    return someval
    

    似乎多次发生:

    在22号线返回呼叫3

    在22号线返回呼叫3

    在22号线返回呼叫3

    任何东西的控制流中都没有一致的逻辑:(我也非常确信我可以编写简单的递增代码来计算方法被调用的次数。绝对的,令人沮丧的,胡说八道的。我甚至把epoch时间放在对sapi.write()的每个调用旁边,以确保不会无意识地重复代码。它们是独一无二的:S

    是时候把Apache、python、mod wsgi和其他软件都挖出来重新开始了。

    解决了的

    谁知道它是什么,但撕掉了Apache、mod_python、mod_wsgi和几乎所有与HTTP相关的东西,重新安装解决了这个问题。有件事是 相当破碎 但现在看来还行:)