3

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

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

4

4 回答 4

5

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

还没有人为 R3重新创建该fastcgi://方案。我说“重新创建”是因为 R3 具有与 R2 完全不同的端口模型，因此端口方案根本不能在两个平台之间移植。此外，R2/Command 端口方案是内置的本地代码，即使它是开源的，也无法移植到 R3，因为 R3 的系统模型也不同。而且不管它的可移植性如何，R2 都包含许多 Rebol Technologies 无权开源的商业许可代码——几乎所有它可以开源的东西都已经进入了 R3。因此，如果它不存在，则可以安全地假设它根本不兼容或不可打开。

fastcgi://在 R3 中使用遵循 R3 模型的全新方案从头开始会更快、更容易。即使我们拥有 R2 源代码，最大的帮助也将是记录 FastCGI 协议，并且 AFAIK 该协议在其他地方有更好的文档记录。在这种情况下，创建一个针对此类事情优化的主机端口可能是一个好主意，这在 R3 中更容易做到。

从好的方面来说，据我记忆，FastCGI 协议做起来并不难，而且新的 R3 端口模型更适合这种事情，所以从头开始可能不会太难。如果幸运的话，这一切都可以在仅在常规 R3 解释器上运行的用户代码中完成，无需主机代码调整。因此，新闻不必那么糟糕。

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

这实际上取决于您要做什么，以及您如何设置。CGI 每次都有启动进程的开销，所以只有当进程启动开销明显小于请求的其余开销（例如文件系统或数据库访问）时，它才会很快。Rebol，尤其是 R2，有大量的进程启动开销，因为它是一个解释器，在启动时有一些内置的解释代码要加载。您可以通过使用 SDK 仅使用您需要的代码创建您的应用程序来最小化启动开销，但这在您的特定情况下可能仍然没有足够的帮助（不知道您正在尝试做什么）。

FastCGI 是一种通过运行进程外应用服务器而不是为每个请求启动一个新进程来消除该进程启动开销的方法。对于像 Rebol 这样具有显着流程启动开销的东西，节省的成本同样显着。

您需要考虑的一件事是，R2 在大多数情况下都有一个单线程/进程模型，因此如果您想处理多个并发请求，您要么必须在同一进程中分部分执行它们（例如 Node.js）。 js) 或让 FastCGI 分配多个服务器进程来独立处理多个请求，或者两者兼而有之。如果这种情况令人生畏，请务必向 Rebol 专家寻求建议，或者只是设置 FastCGI 以启动更多应用程序服务器以同时运行。

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

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

祝你好运！

于 2013-03-02T22:19:57.083 回答
4

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

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

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

也许您的代码（或您使用的库）的一小部分有延迟或短暂的等待（可能对数据库服务器造成一些网络延迟）。

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

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

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

于 2013-03-03T17:17:11.533 回答
3

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

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

于 2013-03-11T21:36:35.013 回答
1

其他一些方法：

  • 让 apache 充当真正的 rebol-webserver 的代理，比如 cheyenne。让它在启动时运行等更复杂。

  • 通过管道在另一种语言后面运行 rebol。使用具有 fastcgi 的语言。

  • 运行 rebol 作为 tcp-daemon，让 fastcgi 语言联系它。

于 2013-03-11T18:57:40.497 回答