1

最后

进一步的测试表明，在较新版本的 G-WAN 中，一切都按预期工作。

原始 我正在处理大文件，G-WAN 似乎非常适合我的用例，但我似乎无法将我的注意力集中在流式传输到客户端的内容上。

我想避免缓冲响应，因为内存会消耗得非常快。

4

3 回答 3

2

源代码现已发布

谢谢。您得到的值显然是错误的，这很可能来自定义 CLIENT_SOCKET 枚举的 gwan.h 文件中的不匹配。等待与可执行文件同步的文件的下一个版本。

请注意，如下所述，您不必为流式传输文件处理 CLIENT_SOCKET - 无论是本地文件还是远程文件 - 因为本地文件由 G-WAN 流式传输，而远程文件将使用 G-WAN 的反向代理更好地提供服务。

从gwan复制到磁盘和服务效率低下，在内存中缓冲文件也效率低下

G-WAN 与 Nginx 和许多其他的一样，已经在使用sendfile()，因此您无需为“将大文件流式传输到客户端”做任何事情。

我查看了 sendfile() 但找不到 gwan 存储客户端套接字的位置。我尝试使用 CLIENT_SOCKET 但它没有用

CLIENT_SOCKET无法返回客户端套接字的唯一方法是使用与可执行文件gwan.h版本不匹配的标头。gwan

通过使用 G-WAN connection handler，您可以绕过 G-WAN 的默认行为（我假设这是您尝试过的）......但同样，这是不必要的，因为 G-WAN 已经完成了您想要实现的目标（如上所述）。

考虑到这一点，这里有几点关于 G-WAN 和sendfile()：

  • 旧版本的 G-WAN 意外禁用sendfile()- 不要使用它，确保您使用的是更新版本。

  • 4 月的公开版本在关闭连接时过于小心（减慢了非保持连接），并且sendfile()仅用于大于一定大小的文件。

  • 最新的开发版本sendfile()用于所有静态文件（默认情况下，由于它混淆了太多用户，我们禁用了缓存，可以在全局、每个连接或特定资源中显式恢复）。

因此，对于大文件测试负载，G-WAN 现在比我们测试过的所有其他服务器都快。

我们还极大地重新设计了内存消耗以达到无与伦比的水平（Nginx 内存消耗的一小部分） - 即使使用 sendfile() 提供的大文件也是如此。

G-WAN 在启动时on a 6-Core Xeon占用 2.2 MB RAM（没有编译和加载脚本，如 servlet 和处理程序）：

> Server 'gwan' process topology:
---------------------------------------------
  6] pid:4843 Thread
  5] pid:4842 Thread
  4] pid:4841 Thread
  3] pid:4840 Thread
  2] pid:4839 Thread
  1] pid:4838 Thread
  0] pid:4714 Process RAM: 2.19 MB
---------------------------------------------
Total 'gwan' server footprint: 2.19 MB

相比之下，Nginxworker_connections 4096;在启动时吃掉了 15.39 MB：

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:4703 Process RAM: 2.44 MB
  5] pid:4702 Process RAM: 2.44 MB
  4] pid:4701 Process RAM: 2.44 MB
  3] pid:4700 Process RAM: 2.44 MB
  2] pid:4699 Process RAM: 2.44 MB
  1] pid:4698 Process RAM: 2.44 MB
  0] pid:4697 Process RAM: 0.77 MB
---------------------------------------------
Total 'nginx' server footprint: 15.39 MB

而且，与 Nginx 不同的是，G-WAN 可以处理超过 100 万个并发连接，而​​无需预先预留内存（顺便说一下也没有任何配置）。

如果你配置 Nginx ，worker_connections 1000000;那么你有：

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:4568 Process RAM: 374.71 MB
  5] pid:4567 Process RAM: 374.71 MB
  4] pid:4566 Process RAM: 374.71 MB
  3] pid:4565 Process RAM: 374.71 MB
  2] pid:4564 Process RAM: 374.71 MB
  1] pid:4563 Process RAM: 374.71 MB
  0] pid:4562 Process RAM: 0.77 MB
---------------------------------------------
Total 'nginx' server footprint: 2249.05 MB

Nginx 甚至在接收到任何连接之前都在吃掉 2.2 GB 的 RAM！

在相同的场景下，G-WAN 只需要 2.2 MB 的 RAM（少 1024 倍）。

而且对于大文件，G-WAN 现在比 Nginx 更快。

我想从远程源流式传输大文件

sendfile()正如您所说： “我想从远程源流式传输大文件”可能不是您要查找的内容。

在这里，如果我正确理解您的问题，您想从远程存储库中继大文件，使用 G-WAN 作为反向代理，这是一个完全不同的游戏（与提供本地文件相反）。

最新的 G-WAN 开发版本具有通用 TCP 反向代理功能，可以使用 G-WAN 进行个性化设置connection handler。

但是在您的情况下，您只需要一个盲中继（没有流量重写）尽可能快，而不是允许您过滤和更改后端服务器回复。

Griffin 提到的splice()系统调用是一种（零拷贝）方式——而 G-WAN（高效的基于事件和多线程）架构将会创造奇迹——尤其是它的低 RAM 使用率。

G-WAN 可以在未来的版本中做到这一点（这比改变流量更简单），但这是一个非常垂直的应用程序，而不是 G-WAN 的主要目标是让 Web/Cloud 开发人员编写应用程序。

无论如何，如果您需要这种效率水平，G-WAN 可以帮助您达到新的性能水平。在 G-WAN 的网站上联系我们。

于 2013-10-24T07:43:26.867 回答
1

有一个很好的 require 功能示例，也包含在 gwan 应用程序中。

http://gwan.com/source/comet.c

希望这可以帮助。

于 2013-10-23T15:11:50.173 回答
0

我认为您可能指的是 http 流，而不是彗星 - 在这种情况下，gwan 提供了一个 flv.c 连接处理程序示例。此外，您可以根据需要使用 csendfile()进行文件的零拷贝传输或splice()系统调用。

于 2013-10-23T22:11:31.483 回答