如何分析 Perl Web 应用程序？
我正在开发一个使用 Perl 的 Web 应用程序，我需要研究加速该应用程序的某些部分。
我想我应该开始分析我想要调查的部分的特定调用。 我已经对 Perl 代码进行了一些分析，但不幸的是，我发现的大多数内容都表明我应该从命令行使用 -d:DProf myapp 运行我的 Perl 代码。 这对我来说不太适用，因为我的代码位于网络应用程序中。 我确实找到了一种方法来让分析与 apache 一起工作，但不幸的是，从分析器返回的“最常用”模块都是 CPAN 模块——Class::xyz 等。不是很有帮助。
除了我将“计时器”代码注入到我希望分析的方法中以仅针对这些方法之外，还有人知道有什么好方法吗？ 我想过编写一个测试脚本并对其进行分析，但由于我正在处理的代码的性质，这需要比我希望做的更多的工作。
I am working on a web app that uses Perl and I need to look into speeding up portions of the app.
I thought I'd start profiling the particular calls for the portion I wish to investigate. I've done some searching on profiling Perl code, but unfortunately most of what I find says that I should run my perl code with -d:DProf myapp from the command line. That doesn't quite work for me since my code is within a web app. I did find a way to get the profiling to work with apache, but unfortunately, the "most used" modules that came back from the profiler were all CPAN modules -- Class::xyz, etc etc etc. Not terribly helpful.
Does anyone know of a good way besides me injecting "timer" code into the methods I wish to profile to target just these methods? I've thought of writing a test script and profiling that but due to the nature of the code I'm working on that would require a bit more work than I'm hoping to have to do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您是否尝试过 Devel::NYTProf （比 Devel::DProf 好得多），可以在Apache下工作吗？ 您使用哪个网络服务器？ 这是普通的 CGI 脚本、mod_perl 脚本还是其他东西？
如果您正在做数据库工作，DBI::Profile 可以对您的查询进行基准测试，这是另一个程序中正在发生的工作。
然而，真正的技巧是组织代码，以便您可以进行全方位的测试和分析，而不必在最后将它们放在一起以发现某些内容很慢。 这在短期内对救火没有太大帮助，但从长远来看确实可以防止事情变成火灾。 还有各种方法可以伪造网络服务器环境等等，但这是一个不同的问题。 :)
Have you tried Devel::NYTProf (much better than Devel::DProf), which can work under Apache? Which webserver are you using? Is this a vanilla CGI script, a mod_perl thing, or something else?
If you're doing database stuff, the DBI::Profile can benchmark your queries, which is work happening in another program.
The real trick, however, is to organize the code so that you can do the full spectrum of testing and profiling without having to put it all together at the end to find out something is slow. That won't help you much in the short term to fight fires, but it does prevent things from becoming fires in the long run. There are also various ways to fake the webserver environment and so on, but that's a different question. :)
如果您使用 CGI.pm，您可以在命令行上将参数传递给 Perl 脚本，CGI.pm 会将它们解释为通过 HTTP 作为参数传递。 因此，如果您正在调试，例如
http://example.com/scripts/example.pl ？action=browse&search=grommet&restrict=blah
然后你可以从命令行调用，例如
perl -d:NYTProf documentroot/scripts/example.pl 'action=browse&search=grommet&restrict=blah'
If you're using CGI.pm, you can pass arguments to your perl script on the command line and CGI.pm will interpret them as if they were passed as parameters over HTTP. So if you're debugging, e.g.
http://example.com/scripts/example.pl?action=browse&search=grommet&restrict=blah
then you could just call from the command line, e.g.
perl -d:NYTProf documentroot/scripts/example.pl 'action=browse&search=grommet&restrict=blah'
您可以将 Benchmark 核心模块与 结合使用：如果您确实想在内部计时，请选择hireswallclock选项。 但实际上，您应该能够从命令行进行分析。 您可能必须编写测试脚本来模拟 CGI 请求的某些部分，但 DProf 在查找性能瓶颈时可能极其有用。
特别是，查找您的代码在何处调用 CPAN 模块代码。 您可能会在超出必要范围的循环中执行此操作，因此虽然时间花在 CPAN 模块上，但重构代码可以解决问题。
You can use the Benchmark core module with the :hireswallclock option if you really want to time things internally. But really, you should be able to profile from the command line. You might have to write test scripts to emulate certain portions of a CGI request, but DProf can be extremely useful when looking for performance bottlenecks.
In particular, look for where your code is calling the CPAN module code. You may be doing this in loops far more than necessary, so while the time is spent in the CPAN module, refactoring your code can fix the problem.
我意识到现在有点晚了，但这就是为什么最好使用 CGI::Application 或其他架构，其中 Web 应用程序只是一段非常简短的面向 Web 的代码，它利用您编写的一堆模块来实现实际功能。 使用这样的设计可以非常简单地从命令行分析（或简单地测试）任何模块，无论是单独还是集体，而不必担心 Web 方面。
I realize it's a bit late for it at this point, but this is one of the reasons why it's good to use CGI::Application or another architecture in which the web app is just a very brief bit of web-facing code which makes use of a bunch of modules you've written to implement the actual functionality. Using such a design makes it very straightforward to profile (or simply test) any modules from the command line, either individually or collectively, without having to worry about the web aspect.