☰

在大型 Apache2 服务器中使用 CGI 有什么好处吗？还是我应该只使用 FASTCGI？

tag-icon • tag-icon apache-2.2 fastcgi cgi
在大型 Apache2 服务器中使用 CGI 有什么好处吗？还是我应该只使用 FASTCGI？

我有一个用 PHP 开发的 Web 产品，理论上应该可以支持很多用户。问题是，我保留了 Apache 原样，发现它只是以 CGI 形式运行。这是否非常错误，我应该在 fastcgi 中执行它还是保留原样？

答案1

优先使用 CGI 而不是 fastCGI 或 apache 模块的唯一有效理由是

  1. 为了节约资源，盒子正在提供非常动态页面数量较少
  2. 您需要使用不同的 uid 来调用功能（例如通过 suexec）。
  3. 你的处理引擎（即 PHP 解释器）非常不稳定，或者正在经历多次更改 - 然后仅用于系统测试

如果这些都不适用，那么您的网站将会变得更慢，并且需要更多的资源来运行，因为操作系统需要为每个请求启动一个新进程。

答案2

只需了解两种方法之间的区别：

网络服务器为cgi每个请求启动一个新进程（您想要为浏览器创建响应的脚本）。（如果没有人访问您的服务器，则没有任何进程处于闲置状态）。

您fastcgi拥有一堆所需“脚本”的启动和运行实例。（这种方法可以节省您启动新进程的时间，但您必须控制一堆启动和运行的实例，请谷歌搜索 php-fpm）。

现在该选择什么：如果实际访客数量符合您的“理论”预期并且您遇到糟糕的性能：考虑从“cgi”切换到“fastcgi”。无论如何，您都应该阅读“fastcgi”以加深您的技能。但只要用户数量很少且速度“正常”，就不需要采取任何（硬性）行动。

答案3

什么是“大规模”？有些人认为是每月 1000 万次页面浏览量，有些人认为是每小时 1000 万次页面浏览量。对您来说，这是什么？

您在评论中提到的“每天 1.5k 次访问”当然不是一个很大的数字，而传统的 CGI 可以毫无问题地处理这种流量。根据您系统上运行的 Web 应用程序，传统的 CGI 可能会处理比您当前流量繁忙一百倍的流量。

但是让我们忘记这些数字。

FastCGI 比传统 CGI 更快，因为已经有正在运行的工作进程在等待处理新请求。在传统 CGI 中，每个请求都会产生一个新进程。理论上，FastCGI 可能已经帮助您缩短了网站响应时间，这完全取决于当前的瓶颈是否是您的 Web 应用程序（例如，实际瓶颈是数据库调用）。

相关内容