数据检索吞吐量-ETS查找与进程间消息传递

Question

假设我们有一个涉及数千个过程的erlang应用程序。 假设有一个单一的资源X，它可能是一个元组，一个列表或任何erlang术语，所有这些过程可能随时需要从中读取/挑选出一些东西。

此类事件的一个示例是API系统，在该系统中，客户端进程可能需要在远程计算机上进行读写。 碰巧，您不想为每个读/写请求创建一个新的连接。 因此，您要做的就是创建一个连接池，将它们视为开放管道/插座/通道的池。

现在，该资源池将由成千上万个进程共享，这样对于每个读取或写入需求，您都希望该进程检索任何可用的开放通道/资源。

问题是，如果我有一个进程（单个进程）在其进程字典中或在其接收循环中都拥有此信息，该怎么办？ 这意味着所有进程在需要免费资源时都必须向该进程发送消息。 由于对该单一资源的需求很高，因此该单一进程随时都有巨大的邮箱。

或者我可以使用ETS表，并且只有一行，例如#resources{key=pool,value= List_of_openSockets_or_channels} 。 但这意味着，我们所有的过程都将尝试在相同的瞬时时间（高概率）从ETS表读取同一行。

如果10,000个进程尝试从同一行/几乎同一时间读取同一行/记录，那么ETS表将如何处理？ 但是，如果我使用一个进程，则为它的邮箱，如果有10,000个进程同时向其发送一条消息以获取相同的资源（并且它需要答复每个请求者）。 请记住，此操作可能发生得如此频繁。 哪种选择（不考虑进程失败的可用性问题）可以提供更高的吞吐量，从而使进程更快地获得所需的信息？

还有没有其他更好的方法来处理Erlang VM中的高要求数据结构，即使它们都同时需要该资源，它也可以提供对数百万个进程的快速访问？

Answer 1

简短答案：个人资料。 尝试不同的方法并验证系统的行为。

首先，我将看看ETS的{read_concurrency, true}选项。 从文档中 ：

{read_concurrency，boolean（）}性能调整。 默认为false。 设置为true时，该表针对并发读取操作进行了优化。 在具有SMP支持的运行时系统上启用此选项后，读取操作将变得便宜得多。 特别是在具有多个物理处理器的系统上。 但是，读和写操作之间的切换变得更加昂贵。 当并发读取操作比写操作更为频繁时，或者当并发读写发生较大的读写突发时（即，许多读取未被写入中断，而许多写入未被中断）时，通常需要启用此选项。读取）。 当公共访问模式是重复的几个读操作和几个写操作交织在一起时，您通常不希望启用此选项。 在这种情况下，启用此选项将导致性能下降。 read_concurrency选项可以与write_concurrency选项结合使用。 当大的并发读取突发和大的并发写入突发很常见时，您通常希望将它们组合在一起。

其次，我将研究缓存的可能性。 进程仅读取一次还是多次读取该信息？ 如果他们多次访问它，则可以读取一次并将其存储在过程状态中。

第三，您可以尝试在整个系统中复制和分发该信息。 分而治之。

Answer 2

如果使用过程方法，为了避免所有读取请求在“服务器”过程的消息队列上序列化， 必须进行复制。

使用带有read_concurrency的ETS表会更自然，这是我在开发并行版本的read_concurrency使用的东西。 但是，在这种情况下，ETS的访问从来都不是瓶颈。