Perl Web 框架之间是否有任何性能比较？答案

【问题标题】：Is there any performance comparison between Perl web frameworks?Perl Web 框架之间是否有任何性能比较？
【发布时间】：2011-06-08 21:32:36
【问题描述】：

我看到有人提到 Embperl 是最快的 Perl Web 框架（听起来像是未经证实的观点，而且过时了）。

我想知道是否对主要稳定 Perl Web 框架的相对速度达成共识，或者理想情况下，在相同示例 Web 应用程序或单个功能（例如会话处理或表单）的实现之间进行某种基于事实的性能比较数据处理）等...？

UPDATE：这个问题具体是关于不同框架的速度比较，执行相同/等效的任务。我很欣赏这些善意，但我已经知道速度不是我应该考虑的唯一标准。我不是在寻求哲学建议。信不信由你，作为框架，您实际上可以通过在它们上运行相同目的的任务/代码/应用程序来逐个比较它们的速度（例如，使用一组给定的模板化插入呈现给定的表单等。 .)，即使每个框架的全部功能不是 100% 相同。

【问题讨论】：

你不会把拖车比作跑车吧？如果您需要厨房，那么跑车的速度根本不重要。所以：这取决于;)
您可能需要将其范围缩小一点。“Web 框架”是一个如此庞大的类别。当然，速度取决于您如何使用它等。查看代码可能会有所帮助，但我猜其他决定对性能的影响大于代码的“速度”..
关于您的更新：我仍然认为在结果几乎毫无用处的比较中投入大量精力是没有多大意义的。所以我认为没有人做过。
@Mugen - 如果您可以选择 3-4 个框架以及所有这些框架都支持的功能要求列表，那么速度很重要。为了使您的第一条评论中的示例更加真实，如果您需要 2 个座位、一条安全带和足够的空间来存放一个健身包，那么突然的跑车听起来比拖车更好，因为它们都符合条件。如果我需要厨房，我会非常明确地围绕“哪些 Perl Web 框架有厨房？”提出我的问题
Øyvind Skaar - 您说得有些正确（性能还有其他因素），但确实存在一些潜在的平台差异（例如，请参阅 bvr 答案中的链接以获取证据）。

标签： perl performance web-frameworks catalyst embperl

【解决方案1】：

我不想进入解释讨论（对于大多数现实世界的场景，这些开销根本没有影响） - 但这是我的测试：

1。纯普莱克

zby@zby:~/progs/bench$ cat app.psgi 

sub {
   my ( $env ) = @_;
   return [
       200,
       [ 'Content-Type' => 'text/text' ],
       [ 'Hello World' ]
       ];
}
zby@zby:~/progs/bench$ plackup
HTTP::Server::PSGI: Accepting connections at http://0:5000/

用简单的ab -n 10000 我明白了

每秒请求数：2168.05 [#/sec]（平均值）

2。舞者

zby@zby:~/progs/bench$ cat dancer.pl 
 #!/usr/bin/perl
           use Dancer;

           get '/' => sub {
               return "Why, hello there";
           };

           dance;
zby@zby:~/progs/bench$ perl dancer.pl 
>> Dancer server 1950 listening on http://0.0.0.0:3000
== Entering the development dance floor ...

通过类似的 ab 测试，我得到 Requests per second: 1570.49 [#/sec] (mean)

3。 Mojolicious::Lite

zby@zby:~/progs/bench$ cat mojo.pl 
 # Using Mojolicious::Lite will enable "strict" and "warnings"
    use Mojolicious::Lite;

    # Route with placeholder
    get '/' => sub {
        my $self = shift;
        $self->render(text => "Hello!");
    };

    # Start the Mojolicious command system
    app->start;
zby@zby:~/progs/bench$ perl mojo.pl daemon
Sat Jan 22 20:37:01 2011 info Mojo::Server::Daemon:320 [2315]: Server listening (http://*:3000)
Server available at http://*:3000.

结果：每秒请求数：763.72 [#/sec]（平均值）

4。催化剂。

很遗憾，代码太长，无法在此处完整呈现，但 Root 控制器包含：

sub index :Path :Args(0) {
    my ( $self, $c ) = @_;

    # Hello World
    $c->response->body( 'Hello World' );
}

结果是：

每秒请求数：727.93 [#/sec]（平均值）

5。 WebNano

zby@zby:~/progs/bench$ cat webnano.psgi

{
    package MyApp;
    use base 'WebNano';
    1;
}

{
    package MyApp::Controller;
    use base 'WebNano::Controller';

    sub index_action {
        my $self = shift;
        return 'This is my home';
    }
    1;
}    
MyApp->new()->psgi_callback;
zby@zby:~/progs/bench$ plackup webnano.psgi 
HTTP::Server::PSGI: Accepting connections at http://0:5000/

结果：

每秒请求数：1884.54 [#/sec]（平均值）

这将在添加更多功能后发生变化。

【讨论】：

这有点没有意义，因为您实际上是在对 Web 服务器进行基准测试。尝试在 Feersum（而不是 HTTP::Server::PSGI）上运行您的 Plack 应用程序，您可能会获得每秒 10 倍的请求数。尝试在您的应用程序中实际做一些事情，您会发现所有框架的性能都是相同的。
好的 - 我添加了更多免责声明。它只是数据——它的意义与你的解释一样多。例如，您可以使用这些数据来支持您的论点，即对于实际应用程序，框架产生的开销可以忽略不计 :)
您正在比较 Web 服务器（plackup、mojo daemon 等）

【解决方案2】：

这是 perl 框架之间的一个比较，在速度（启动）和框架本身消耗的内存方面。它有点旧（2008 年），所以它不会比较像 Plack 这样的新东西。

http://mark.stosberg.com/blog/2008/11/startup-benchmarks-for-mojo-catalyst-titanium-httpengine-and-cgiapplication.html

【讨论】：

谢谢！！！ +1，我现在接受这个，除非将来添加更全面/有用的东西。
和所有：请记住，基准测试是针对 cgi 环境的。对于大多数框架，您可能希望使用 mod_perl。
我写了上面的比较，不会选择基于上面的框架。一旦你有一个真正的应用程序用于你自己的目的，就组合起来进行基准测试。您可能会发现，从大局来看，框架所起的贡献很小，而较慢的框架可能是更好的选择，因为除了速度之外还有其他特性。

【解决方案3】：

我知道这不会直接回答您，但我认为不存在最新的比较，而且我知道不存在全面的比较。至少要花几周的时间来做一个彻底的基准测试，因为现在 Perl 中有很多框架，有很多 DB/模板/服务器排列，并且应用程序的不同类型的使用模式可能会产生重大的性能差异也是。

我相信，如果将 Mark 的简单 2008 年基准作为您的任务的答案，您会错过很多。部署的重要性不亚于网络框架的速度。例如，Catalyst 不会赢得一场原始的“hello world”速度大战，但 BBC 的视频 Catalyst 应用程序可以提供 1,000 个并发视频。灵活性、可扩展性和对不同部署的支持成为选择 Web 框架的重要因素。

Plack 是新的和主要的。在短短一年内，它就获得了巨大的采用、中间件/插件的增长，以及几乎所有框架的支持。 plack 应用程序的Starman 引擎速度惊人，支持热重载和工作进程递增/递减。由于几乎所有的 Perl 框架都可以作为 .psgi 运行，现在你可以在 Starman + nginx（或 lighttpd）上运行任何你想要的东西。在过去的两年中，Web 框架领域出现了数十种良好的部署组合以及相当多的更改和新条目。

如果您正在做现代 Web 工作，请务必选择支持 websocket 的套件。与传统的 Ajax 相比，仅此一项就会显着提高性能；使用 websockets，小请求/响应可以小 100 倍/轻。

旁注：modperl 可能不是此时选择的最佳持久部署，除非您需要深度挂钩到请求周期。它有许多警告和皱纹，并将您与 apache 联系在一起（一个很棒的服务器，但从长远来看不是最快的选择）。

狩猎愉快！

2016 年 10 月 20 日更新：uWSGI is a fantastic match for PSGI Perl 中的应用程序。

【讨论】：

Apache/mod_perl 可能不是我搜索的灵活选项，但由于我还不确定，很高兴您提到了其他选项。 +1 以获得非常彻底和周到的答案。
websockets 听起来很有趣 - 感谢您提到这个想法。然而，实际上，它们似乎几乎没有 cient 端支持（没有 IE，没有生产 FF，并且由于 FF4 和 Opera 中的安全问题而关闭（en.wikipedia.org/wiki/WebSockets#Browsers_supporting_WebSocket）
@DVK，谢谢！ Re:websockets，是的，现在还早，但它很棒而且很快就会出现，例如，IE 9 看起来对 html5 有非常很好的支持。我还没有尝试过，其中一些代码看起来有点幼稚，但却是一个超级酷的想法：The Graceful WebSocket — 让您编写 websocket 代码，必要时降级为 Ajax。

【解决方案4】：

TechEmpower 对框架性能进行了一些很好的比较。见http://www.techempower.com/benchmarks/

截至目前，它们已包含 4 个 perl 框架（Dancer、Kelp、Mojolicious、Web::Simple）以及来自其他语言的许多框架。如果需要，可以过滤结果以仅显示 Perl 框架。

【讨论】：