fastCGI 进程之间如何共享数据？
我编写了一个简单的 perl 脚本，通过 Apache 上的 fastCGI 运行该脚本。该应用程序加载一组 XML 数据文件，这些文件用于根据传入请求的查询参数查找值。据我了解，如果我想增加应用程序可以处理的并发请求量，我需要允许 fastCGI 生成多个进程。每个进程都必须在内存中保存 XML 数据的重复副本吗？有没有一种方法可以进行设置，以便我可以将 XML 数据的一个副本加载到内存中，同时增加处理并发请求的能力？
I've written a simple perl script that I'm running via fastCGI on Apache. The application loads a set of XML data files which are used to lookup values based upon the the query parameters of an incoming request. As I understand it, if I want to increase the amount of concurrent requests my application can handle I need to allow fastCGI to spawn multiple processes. Will each of these processes have to hold duplicate copies of the XML data in memory? Is there a way to set things up so that I can have one copy of the XML data loaded in memory while increasing the capacity to handle concurrent requests?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如 pilcrow 正确回答的那样，FastCGI 没有提供在进程之间共享数据的特殊方法，并列出了减少内存使用的传统方法。
另一种可能性是让持久的非 FastCGI 进程读取 XML 文件并充当 FastCGI 进程的数据服务器。其效率取决于查询的复杂程度以及需要传入和传出的数据量，但它允许将数据的单个副本保留在内存中。
As pilcrow correctly answered, FastCGI provides no special way to share data between processes and lists traditional ways to reduce memory usage.
One additional possibility is to have a persistent, non-FastCGI process read the XML file and act as a data server for the FastCGI processes. The efficiency of this depends on how complicated the queries are and how much data needs to be passed in and out, but it would allow a single copy of the data to remain in memory.
内存在单独的 FastCGI 进程之间共享，就像在普通的单独进程之间一样，也就是说，就我们的目的而言，数据不共享。
（FastCGI 允许单个进程连续处理多个请求，从而避免了重新初始化、重新读取配置和 XML 数据的需要，例如，在该进程第一次服务之后的每个请求。
）好的一面是，任何能够减少不同进程之间 XML 内存占用的技术都应该在这里发挥作用。您可以将文件读入共享内存（这可能很难同步和更新），选择低内存 XML 解析器，或间接访问信息，比如说通过 XML 数据的“编译”GDBM 或您写入的自定义服务器回答查询。
Memory is shared between separate FastCGI processes just as it is between ordinary, separate processes, which is to say that, for our purposes, the data is not shared.
(FastCGI lets a single process handle multiple requests serially, avoiding the need to re-initialize, re-read config and XML data, for example, with each request after the first served by that process.)
On the upside, any technique that would work to reduce the in-memory footprint of your XML between separate processes should work here. You might read the files into shared memory (which can be tricky to synchronize and update), select a lower-memory XML parser, or access the information indirectly, say through a "compiled" GDBM of your XML data or a custom server you write to answer queries.