我正在使用Perl的Web应用程序上工作，我需要研究加速应用程序的某些部分。

我以为我将开始分析要调查的部分的特定调用。我已经完成了对Perl代码进行概要分析的搜索，但是不幸的是，我发现的大部分内容都表明我应该从命令行使用-d：DProf myapp来运行我的perl代码。因为我的代码在Web应用程序中，所以这对我来说不太有效。我确实找到了一种使分析与apache一起使用的方法，但是不幸的是，从探查器返回的"最常用"模块都是CPAN模块-Class :: xyz等，等等。并不是很有帮助。

除了我将"计时器"代码注入到我要分析的方法中以这些方法为目标的方法之外，还有谁知道一种好方法吗？我已经考虑过编写一个测试脚本并进行概要分析，但是由于我正在处理的代码的性质，与我希望做的相比，它需要做的工作要多一些。

解决方案

如果我们确实想在内部计时，则可以将Benchmark核心模块与：hireswallclock选项一起使用。但实际上，我们应该能够从命令行进行概要分析。我们可能必须编写测试脚本来模拟CGI请求的某些部分，但是DProf在寻找性能瓶颈时非常有用。

特别是，查找代码在哪里调用CPAN模块代码。我们可能在循环中执行此操作的次数远远超过了必要，因此，尽管在CPAN模块中花费了时间，但是重构代码可以解决此问题。

我们是否尝试过可以在Apache下运行的Devel :: NYTProf(比Devel :: DProf更好)？我们正在使用哪个Web服务器？这是香草CGI脚本，mod_perl还是其他东西？

如果我们正在做数据库工作，则DBI :: Profile可以对查询进行基准测试，这是在另一个程序中进行的工作。

但是，真正的诀窍是组织代码，以便我们可以进行全部测试和性能分析，而不必在最后将所有内容组合在一起以发现某些问题很慢。这在短期内不会对我们有太大帮助，但是从长远来看，它确实可以防止火灾。伪造Web服务器环境的方式也有多种，等等，但这是一个不同的问题。 :)

如果我们使用的是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'

我意识到在这一点上为时已晚，但这是使用CGI :: Application或者其他架构的良好原因之一，其中Web应用程序只是一小段使用Web的面向Web的代码为实现实际功能而编写的一系列模块中的一个。使用这样的设计，可以很容易地从命令行中单独地或者共同地配置(或者简单地测试)任何模块，而不必担心Web方面。