【问题标题】:Multi-threaded Windows Service - Erlang多线程 Windows 服务 - Erlang
【发布时间】:2011-04-02 16:55:17
【问题描述】:

我将告诉我必须解决的问题,如果我走在正确的道路上,我需要一些建议。

问题是:

我需要创建一个接收请求并执行某些操作的 Windows 服务应用程序。 (Socket通信)这个动作是执行一个脚本(可能是lua或perl)。这个脚本模拟客户端的业务规则,在数据库中查询,在网站中发出请求,然后向客户端发送响应。

有 3 个强制性要求:

  1. 服务会同时收到大量请求。所以我想用worker的线程模型。
  2. 服务必须具有高吞吐量。我将在同一秒内收到许多请求。
  3. 低延迟:我必须非常快速地响应这些请求。

每个请求都会生成一个日志条目。由于 I/O 时间大,我无法在脚本执行的同时将这些日志条目写入物理磁盘。可能我会在内存中创建一个队列,其他线程会消耗这个队列并写入磁盘。

以后有可能两个woker的线程要改消息。

我必须为此服务制定协议。我正在考虑使用 Thrift,但我不知道所涉及的开销。也许我会制定自己的协议。

要编写 Windows 服务,我在考虑使用 Erlang。这是个好主意吗?

有没有人有解决这个问题的建议/提示?哪种语言更适合编写此服务?

【问题讨论】:

  • 不知道“很多”、“高”和“非常快”究竟是什么数量,这是一个主观问题。
  • @spender: 是的,我也准备好注意到这一点,但后来又想起有时几乎不可能甚至非常粗略地指定这一点
  • 每秒请求:大约每秒 1k 延迟:大约 600 毫秒。取决于脚本中实现的业务规则。

标签: windows erlang latency thrift throughput


【解决方案1】:

是的,如果您熟悉或准备学习 Erlang,它是一个不错的选择。使用 Erlang,您不需要任何工作线程,只需以 Erlang 风格实现您的服务器,您将自动收到多线程解决方案。

不确定如何将 Erlang 程序转换为 Windows 服务,但可能是可行的。

从多个线程写入同一个日志文件是次优的,因为需要锁定。最好有一个日志条目队列(无锁?)和一个单独的线程(Erlang 进程?)将它们写入文件。顺便说一句,您确定用另一种语言执行外部脚本比将日志记录写入文件要快得多吗?

与 Thrift 免费提供的相比,使用自己的序列化库可能会获得更好的性能,这是值得怀疑的。另一个选项是Google Protocol Buffers,有人声称它更快。

理论上 (!) Erlang 解决方案可能无法为您提供所需的性能。在这种情况下,考虑一种可编译的语言,例如C++ 和异步网络,例如Boost.Asio。但要准备好它比 Erlang 方式复杂得多。

【讨论】:

  • 脚本将执行客户业务规则。脚本执行后,客户希望查看脚本做出的决定。所以这就是为什么我需要一个日志文件。对于客户来说,最好将日志条目写入数据库,因为他们可以在线查询。 Erlang 是否使用进程池来接收请求?还是每次发出请求时都会产生一个新进程?它有很好的表现吗?可以实现进程池吗?
  • 1) 您的脚本很可能会比您的核心逻辑花费更长的时间,因此您的核心性能不会成为瓶颈。 2) 不需要进程池,Erlang 使用轻量级进程,你可以拥有数百万个具有合理良好性能的进程。您只需为每个客户端连接创建(“spawn”)进程
  • 但如果我有一个池,则不需要创建进程。它只是从池中选择一个进程。性能会更好。我对吗?谢谢
  • 只有当创建需要大量时间时,您才是正确的。 Erlang 进程并非如此
  • 在 Windows 上将 Erlang 模拟器作为服务运行 --> erlang.org/doc/man/erlsrv.html
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-07-20
  • 2012-05-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多