Rebol 在 FCGI 设置中的扩展性如何？答案

【问题标题】：How well does Rebol scale in an FCGI setup?Rebol 在 FCGI 设置中的扩展性如何？
【发布时间】：2013-03-02 21:23:39
【问题描述】：

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

而且 afaik，Rebol 仅在 Command 和 SDK 版本中支持 FastCGI，自从 R3 开源以来，这种变化已经或即将发生变化？

【问题讨论】：

在chat room for Rebol and Red（如果可以的话，请加入）中提到我们需要一个 mod_rebol，但你的场景在性能方面听起来很奇怪，让我们在聊天中调试它。跨度>

标签： fastcgi rebol rebol3 rebol2

【解决方案1】：

我已经有一段时间没有使用 Rebol 中的 FastCGI 工具了，所以我不能很好地回答第一个问题，但我可以帮助你解决第二个问题，尽管你可能不喜欢它。

目前还没有人为 R3 重新创建 fastcgi:// 方案。我说“重新创建”是因为 R3 具有与 R2 完全不同的端口模型，因此端口方案根本不能在两个平台之间移植。此外，R2/Command 端口方案是内置的本地代码，即使它是开源的，也无法移植到 R3，因为 R3 的系统模型也不同。而且不管它的可移植性如何，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 工作进程并编写处理程序以同时处理多个请求，这样您将尽可能节省开销。

祝你好运！

【讨论】：

该死！我真的希望全速在 Rebol 中编写应用程序。看来我现在不得不选择另一个平台了。我的脚本目前并不繁重，没有依赖项或数据库调用，但是，我确实有一个非常大、很深（6-7 级）的嵌套块，我为每个请求解析，但我注意到这似乎并不完全影响性能，这告诉我你有它的位置。令人沮丧的是可执行文件的启动时间。
另外 4-5 个请求是我在 Debian 盒子上得到的。有趣的是，我在 Ruby 中有一个类似的脚本（原始的，作为 cgi 脚本运行）做得更多，而且我在同一个盒子上得到了大约 30 rps。它打败了我！但更有趣的是，我在运行 Apache 的 Windows 机器上获得了大约 30 rps（Rebol 和 Ruby 版本）！去图吧！
现在，我不知道编写一个 Apache 模块有多难，但我正在认真考虑为 Rebol 编写一个模块，因为我似乎无法放弃这个想法。但说真的，我担心我会全身心投入其中，没有时间参与手头的真正项目！哈！我想，我们会看到的。感谢您的意见。
检查其他答案。 Rebol 本身没有任何理由为什么您应该每秒收到 4-5 个请求。 10 倍的速度更常见，与 Ruby 相当（具有相似的启动开销）；在某些情况下，速度会快 100 倍，具体取决于硬件和配置。深度嵌套的块很容易解析，所以不是这样。

【解决方案2】：

当我们不知道您要运行什么脚本时，很难回答任何性能问题。 :-) 下面的一些问题可能看起来很愚蠢，但我真的不太了解您尝试 Rebol CGI 的背景。

对于在 Apache 下运行的 CGI 应用程序，每秒 4-5 个请求是不正常的。我可以向你保证，任何一种硬件甚至是十年前的历史，你应该得到的远不止这些。

你在做什么样的测试？对我来说，rebol 启动得如此之快，以至于它可以打开、显示其控制台并在两次刷新之间退出（60Hz），所以我什至看不到它出现。

可能您的代码（或您使用的库）的一小部分有延迟或短暂的等待（可能会导致数据库服务器出现一些网络延迟）。

另外，你有没有测试过服务器的传出网速？

您也可以尝试使用 cheyenne，这是一个使用 Rebol 构建的 Web 服务器，每秒能够处理数百个请求，而脚本本身显然不会花费太多时间。

事实上，cheyenne 和 apache 应该能够相对轻松地使服务器的网络速度饱和...如果您有冗长的脚本，并且需要更多吞吐量，只需添加更多工作人员以执行更多并行任务（只要内存使用在可接受的范围内）

【讨论】：

我会试试夏安。可悲的是，恐怕我不能在这里分享剧本，但请放心，它并没有试图做任何不寻常的事情。请参阅我对 Brian 上面帖子的 cmets。感谢您的意见。
我很好奇，您使用的是什么平台？您的问题是否完全取决于它在那里的安装方式？另外，您使用的是哪个版本的 rebol。看法？核心？
我在 VirtualBox 上的 Ubuntu 上。它有足够的处理器和内存。我认为我的资源也很匮乏，但鉴于相同的脚本 Ruby 似乎胜过 Rebol，这非常令人惊讶。我正在使用 R2 Core。
很奇怪。你提到夏安也很慢......我开始认为你的安装可能有问题。我想知道 rebol 启动是否会变慢。当您在 shell 中启动时，您在 user.r 中是否有任何内容或明显的延迟？它应该是“瞬时的”。
运行库存 Debian/Ubuntu/Cheyenne。不知道在虚拟盒子中运行是否会导致这些异常？我会尝试直接在我的 linux 笔记本电脑上运行相同的设置，然后让你们知道。感谢您的帮助！

【解决方案3】：

如果您可以在使用 Ruby 的同一个机器上获得大约 30 rps 并且在 Windows 机器上的 Ruby 和 Rebol 性能相同，那么很可能是您的 Rebol CGI 和/或配置有问题。

尝试从命令行循环运行您的 Rebol CGI 脚本，以查看缓慢的原因是脚本还是您的 Apache 配置。

【讨论】：

【解决方案4】：

其他一些方法：

让 apache 充当真正的 rebol-webserver 的代理，比如 cheyenne。让它在启动时运行等更复杂。
通过管道以另一种语言运行 rebol。使用具有 fastcgi 的语言。
将 rebol 作为 tcp-daemon 运行，让 fastcgi 语言联系它。

【讨论】：

谢谢 dt2。我试过夏安，但我担心它是不可能的，因为它也很慢。我不知道选项 2 和 3。请您详细说明一下吗？
shairosenfeld.blogspot.de/2011/01/… 你运行 rebol 脚本而不是 exec "/bin/sh"。将 cgi 请求从 ruby 提供给 rebol，等待回答，提供下一个请求。你需要一个组合的协议来分离请求，传递它们的大小或其他东西。