FastCGI已经过时但在某些情况下似乎仍然是正确答案。
似乎Perl / Catalyst Web应用程序的首选部署是使用FastCGI。
FastCGI在Rails中很受欢迎，但似乎不再适用。 （为什么？）
Java世界似乎与FastCGI无关。像Tomcat这样的东西比Apache + FastCGI好吗？
选择FastCGI仍然是一个好主意还是仅仅是一种挥之不去的技术？
泰德
答案 0 :(得分：13)
由于它很大程度上取决于您的设置和要求，我会让“X仍然是正确答案吗？”由你决定。但是，通过查看不同的体系结构，您可以提出一个问题列表，以确定在特定情况下它是否仍然是正确答案。
您要问的问题通常与安全性和灵活性有关。为安全起见，您需要关注principle of least privilege。为了灵活性，您需要知道是否可以运行多个框架，框架的多个版本以及将工作委托给其他任务的容易程度。
对于数据库支持的应用程序的简单Web前端，并非所有这些问题都很重要。您还需要记住，某些建议 nothing 与此处列出的内容有关。许多Web框架将推荐最容易使用其框架设置的架构。他们这样做是因为它有助于让新用户轻松地尝试框架并且不会充斥邮件列表。此外，Java社区倾向于坚持共同点，而不是充分利用手头的平台，因此他们通常会推荐全Java解决方案。
从纯粹的性能角度来看，具有嵌入式框架的单个进程（可能是线程化的）可能会提供最大的性能，因为它可以减少接收请求和产生响应之间的大部分通信开销。
安全性：单个进程必须具有执行每个单个任务所需的所有权限。在简单的应用程序中，这可能不是问题。但是，它可能会提供多种服务
灵活性：可能无法运行同一框架的多个版本（例如，网站不同部分的代码需要不同版本的Java，Rails，Python等）。此外，更改您的设置以在不同的计算机上进行某些工作会变得很痛苦（在虚拟主机上拆分时不那么困难）。
在CGI模型下，您必须为每个请求支付产生新流程的代价。即使在生成进程被认为是便宜的UNIX机器上，如果为每个进程生成一个进程，每秒600个请求将会终止服务器。
安全性：要在不同的用户帐户下生成子进程，您的网关可能会在相当高的权限下运行。
灵活性：多个框架，多个版本，多种语言方法的额外灵活性，但您仍然停留在同一台计算机上。
FastCGI / SCGI方法试图以干净的方式解决CGI流程管理问题。只是让这个过程保持活力。让网关与该进程通信以提供请求。
安全性：由于网关不会产生为请求提供服务的进程，因此网关可以在启用的权限少得多的情况下运行。实际上，如果它只作为一个网关而且本身不做任何工作，那么它几乎不会有任何特权。
灵活性：您可以获得比CGI模型更好的灵活性，因为您可以将请求转发到网络上的任何计算机。
我喜欢FastCGI，因为它给我带来了很高的灵活性（即通过套接字转发的请求）我能负担得起。管理系统不是我的全职工作。我没有开发我托管的所有应用程序。这意味着我寻找最简单的解决方案来托管我尝试托管的任何东西。 FastCGI足以受到主要Web服务器和流行Web框架的支持。添加另一个应用程序通常只是归结为通过FastCGI安装并将所需的URL映射到应用程序。