Windows/Apache 上的 ActivePerl 性能问题
我想请你帮忙。在我们公司，我们在Windows机器上安装了Bugzilla 4.0。为了运行 Perl，我们目前使用 ActivePerl。
问题是，我们有大约 50 个用户定期查询 Bugzilla Web 服务，而服务器无法承受此负载。我们发现，这是由 perl.exe 引起的，perl.exe 在每个请求期间都运行。服务器工作负载 (CPU) 在高峰期间处于 90%。
您是否遇到过此类问题？我们可以进行任何可能的配置来提高性能吗？
我们正在使用：Apache 2.2.17 和 ActivePerl 5.8.9 b829。 预先非常感谢您，这给我们（尤其是我）带来了很多麻烦。
I would like to ask you for help. In our company, we have installed Bugzilla 4.0 on Windows machine. For running perl, we are currently using ActivePerl.
The problem is, that we have around 50 users periodically querying the Bugzilla web service and server can't take this load. We have found out, that it is caused by perl.exe, which is being ran during every request. Server workload (CPUs) are on 90% during peaks.
Have you ever experienced this problems? Is any possible configuration, we can make, to improve the performance?
We are using: Apache 2.2.17 and ActivePerl 5.8.9 b829.
Thank you very much in advance, it causes us (especially me) a lot of trouble.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
随着网站的发展，这是一个相当常见的问题。而且它也不具体限于 Perl。有解决方案。正如一个人提到的，mod_perl 本质上是作为 Apache 模块安装的。它可以通过 Apache::Registry 在某种简单版本中使用，或者您可以通过编写在每个请求阶段与 Apache API 交互的组件来一路完成。无论您对 mod_perl 采取什么方法，都有一些共同的注意事项： 它是一个持久的过程，这意味着（简单来说）Perl 从一个请求到下一个请求都保持驻留，这样您就可以消除启动成本。如果不进行一定程度的清理和重构，CGI 脚本通常无法直接移植到 mod_perl。例如，由于脚本在持久环境中运行，因此全局变量不会在请求之间重置自身。有一大堆“陷阱”需要克服。为此，Apache::Registry 在 mod_perl 环境中更容易处理，但代价是无法提供直接为 API 编程所能提供的 100% 的性能。尽管如此，这是一个非常好的妥协。
另一种选择是 FastCGI，您可以在FastCGI 网站阅读有关它的信息。
编写良好的 CGI 脚本可以通过一些努力移植到mod_perl或FastCGI。因此，这些可能是最不痛苦的方法。有些脚本只需很少的清理即可转换。其他可能需要大量工作，但应该仍然是可能的。
幸运的是，CPAN 上有大量有用的模块可以帮助您使用 mod_perl 或 FastCGI。例如，在 CPAN 上的 Apache::* 层次结构下，您会发现许多设计用于与 mod_perl 配合使用的工具。对于 FastCGI，您甚至会找到与 Catalyst 和 Mojolicious 相关的模块来帮助融合两者，尽管最后两个建议可能需要一些真正的重构。
我发现 Practical mod_perl 作为起点很有帮助（一本 O'Reilly 的书）。
This is a fairly common issue as sites grow. And it's not specifically limited to Perl either. There are solutions. As one person mentioned, there is mod_perl, which is essentially installed as an Apache module. It can be used in a sort of simple version via Apache::Registry, or you can go all the way by writing components that interact with the Apache API at each request phase. Whatever approach you take with mod_perl, there are a few common notes: It is a persistent process, meaning (in simple terms), Perl stays resident from one request to the next, to the next, so that you eliminate startup costs. CGI scripts often cannot be ported directly to mod_perl without some amount of cleanup and refactoring. Since the script runs in a persistent environment, global variables don't reset themselves between requests, for example. There's a whole list of 'gotchas' to overcome. To that end, Apache::Registry is somewhat easier to deal with in a mod_perl environment, at the expense of not providing 100% of the performance horsepower that programming for the API directly can provide. Nevertheless, it's a pretty good compromise.
Another option would be FastCGI, which you can read about at the FastCGI website.
Well written CGI scripts can be ported to mod_perl or to FastCGI with some effort. These are probably the least painful approaches, for that reason. Some scripts can be converted with very little cleanup. Others may require a lot of work, but should be still possible.
Luckily there is a plethora of useful modules on CPAN to assist you in using mod_perl, or FastCGI. Under the Apache::* hierarchy on CPAN, for instance, you'll find many tools that are designed to work with mod_perl. With respect to FastCGI, you'll even find Catalyst and Mojolicious-related modules to help meld the two, though those last two suggestions would probably require some real refactoring.
I found Practical mod_perl to be helpful as a starting point (an O'Reilly book).
深思熟虑：mod_perl
Food for thought: mod_perl