我一直在尝试确定我的 Web 项目是否适合使用 PSGI 实现，但我真的不知道在这个阶段它对我的应用程序有什么好处。
我真的不明白所有的大惊小怪。对我来说，PSGI 似乎是一个框架，它在不同的 Apache 模块之间提供了一个通用接口，让您可以在它们之间移动您的应用程序。例如，轻松地将您的应用程序从在 mod_perl 上运行到 fastcgi 上，并为在这两个选项上运行提供应用程序支持。
是这样吗，还是我错过了什么？
作为我和团队的一员，我不仅参与了应用程序的开发，还进行了服务器的维护和设置工作，我不认为能够在 fastcgi、cgi 和 mod_perl 上运行对我们来说有什么价值, 我们只用 mod_perl 就可以了。
是我误解了 PSGI 功能，还是它不适合我的项目？
【问题讨论】：
标签： perl fastcgi mod-perl2 psgi
忘记 Apache 位。这是一种编写应用程序的方式，因此网络服务器的选择变得不那么相关了。在 $work 我们发现我们的应用程序在升级到 Apache2 后以非常高的 CPU 负载运行后切换到 Plack/PSGI - 对各种 Apache 配置和 NYTProf'ing 进行基准测试无法确定原因，并且使用 PSGI 和 Starman 网络服务器工作得更好对我们来说。
现在一切都由我们的 PSGI 应用程序（URL 重写、静态内容、过期标头等）而不是 Apache 配置在一个地方处理，所以它是 a) Perl，b) 通过我们的标准 /t/ 轻松测试脚本。此外，我们的测试现在正在准确测试用户看到的内容，而不仅仅是基本应用程序本身。
如果您对 Apache 和 mod_perl 感到满意，这可能与您无关，而且我相信其他人将能够给出更好的答案，但对我们来说不必再处理任何与 Apache 相关的事情是这样的解脱本身。测试的便利性，以及只需插入 Data::Dumper 并查看发生了什么而不是与 ModRewrite 和朋友搏斗的能力，是一个巨大的福音。
【讨论】：
借用 chromatic Why PSGI/Plack Matters (Testing) 最近的一篇博客文章，它是这样的：
这是一个从 Python 的 WSGI 和 Ruby 的 Rack 借来的好主意，但是却变成了 Perlish；它是 Web 应用程序开发模式的简单形式化，其中应用程序的入口点是函数引用，出口点是标头信息和响应正文的元组。
就是这样。这是最简单的方法，但这种简单会欺骗很多想要学习它的人。
一个重要的好处是，同上。，
给定一个 Plack 应用程序，您不必部署到 Web 服务器（甚至是本地）来测试您的应用程序，就像它已部署一样 ... Plack 和 TWMP（和 Plack::Test ) 使用定义明确的 Plack 模式将以前很难的事情变成非常容易的事情。他们不是第一个，也不会是最后一个，但他们确实展示了 Plack 的价值。
【讨论】：
开始写了一个答案，50行后我删除了它。仅仅因为不可能告诉（简而言之）为什么 PSGI 非常酷。我也是 PSGI 的新手，但在我的 apache/mod_perl 时代，现在很多事情比以前容易得多。
我可以给你下一个建议：
ps： 如果这里有“Perl Oscar”之类的东西，肯定会提名 MyiagavaSan。 :)
【讨论】：