fastcgi - Rebol在FCGI设置中的缩放程度如何？

Question

我计划在Rebol（目前在Apache 2上为CGI）中编写一个相当不错的Web应用程序，但是最初的性能测试却非常令人沮丧。在应用程序上运行apache基准测试时，我仅得到4-5个请求/秒。我想知道其他人是否也遇到过类似的问题，以及FastCGI是否真的为他们提供了帮助。

而且afaik，Rebol仅在Command和SDK版本中支持FastCGI，自从R3开源以来，这种变化是否会或会很快改变？

Answer 1

自从我在Rebol中使用FastCGI工具以来已经有一段时间了，所以我不能很好地回答第一个问题，但是尽管您可能不喜欢它，但我可以为您解决第二个问题。

还没有人为R3重新创建fastcgi://方案。我说“重新创建”是因为R3具有与R2完全不同的端口模型，因此端口方案根本无法在两个平台之间移植。这是R2 / Command端口方案内置的本机代码的补充，该方案即使是开源的，也不会移植到R3，因为R3的系统模型也不同。而且，无论R2的可移植性如何，R2都包含许多商业许可的代码，而Rebol Technologies无权开放源代码-几乎可以打开的所有内容都已将其纳入R3。因此，如果尚不存在，可以假定它根本不兼容或无法打开。

使用遵循R3模型的全新fastcgi://方案，从R3重新开始会更快，更轻松。即使我们拥有R2来源，它最大的帮助就是记录FastCGI协议，而AFAIK协议则在其他地方更好地记录了该文档。在这种情况下，最好使主机端口针对这种情况进行优化，这在R3中更容易实现。

从好的方面来说，我记得FastCGI协议并不难做到，对于这种情况，新的R3端口模型要好得多，因此从头开始可能并不难。而且，如果幸运的话，所有这些都可以在仅在常规R3解释器上运行的用户代码中完成，而无需修改主机代码。因此，新闻不必那么糟糕。

现在尝试回答您的第一个问题：这取决于。

这实际上取决于您要执行的操作以及您的设置方式。 CGI具有每次启动进程的开销，因此只有在进程启动开销明显小于请求的其余开销（例如文件系统或数据库访问）的情况下它才是快速的。 Rebol，尤其是R2，具有大量的进程启动开销，因为它是一个解释器，在启动时具有一些内置的解释代码要加载。您可以通过使用SDK仅使用所需的代码来创建应用程序，从而最大程度地减少启动开销，但是在您的特定情况下（可能不知道您要执行的操作）可能仍无济于事。

FastCGI是一种通过运行进程外应用服务器而不是按请求启动新进程来消除进程启动开销的方法。对于像Rebol这样的过程，它具有大量的过程启动开销，节省的费用也同样可观。

您需要考虑的一件事是，R2在大多数情况下都具有单进程单线程模型，因此，如果要处理多个并发请求，则必须在同一进程中分多个部分来进行处理（例如Node。 js）或让FastCGI分配多个服务器进程来独立处理多个请求，或者可能两者兼有。一定要向Rebol专家咨询，如果这样的前景令人生畏，或者只是设置FastCGI以启动更多应用服务器同时运行。

因此，使用FastCGI设置每秒可以执行多少个请求，取决于您如何配置FastCGI，如何编写FastCGI处理程序代码以及请求执行的工作量和类型。

它告诉您在CGI模式下每秒收到4-5个请求。速度异常缓慢。在最坏的情况下，Rebol的启动开销几乎没有那么慢。这意味着您的请求做得很多，或者您的RAM不足以一次运行多个CGI进程，或者您的CGI配置不正确。在这种情况下，我不确定FastCGI是否能提供帮助，就像使用更好的硬件或更好地配置Apache一样。尽管如此，请确保您有足够的FastCGI工作进程，并编写处理程序以同时处理多个请求，并且将节省尽可能多的开销。

祝好运！