简体   繁体   English

哪种沟通方式更有效

[英]Which Way of Communication is More Efficient

There are two processes running in the server (LINUX), they are PHPApp and C++App. 服务器(LINUX)中正在运行两个进程,它们是PHPApp和C ++ App。 The PHPApp is written by PHP and C++App is written by C++. PHPApp由PHP编写,而C ++ App由C ++编写。

Now they need to communicate with each other to perform below task: PHPApp sends a request to C++App, when the C++App receives the request it reads data from shared memory and does some calculation, finally return the data to PHPApp. 现在他们需要相互通信才能执行以下任务:PHPApp向C ++ App发送请求,当C ++ App收到请求时,它将从共享内存中读取数据并进行一些计算,最后将数据返回给PHPApp。

There are two methods to do above: 上面有两种方法可以执行:

  1. PHPApp communicates with C++App by sockets. PHPApp通过套接字与C ++ App通信。 C++App will serve as daemon process. C ++ App将充当守护进程。
  2. PHPApp communicates with C++App by calling exec(...) (php has such function). PHPApp通过调用exec(...)与C ++ App通信(php具有此功能)。 No C++App process until there is request from PHPApp, and in this way each request requires one C++App instance. 在没有来自PHPApp的请求之前,没有C ++ App进程,以这种方式,每个请求都需要一个C ++ App实例。

I wonder which way is more efficient? 我想知道哪种方法更有效?

UPDATE 更新
The PHPApp is part of a server software based on Apache, thus there might be hundreds of PHPApp processes sending requests to C++App. PHPApp是基于Apache的服务器软件的一部分,因此可能有数百个PHPApp进程向C ++ App发送请求。 The PHPApp makes request in parallel. PHPApp并行发出请求。

This depends completely on what you are trying to do. 这完全取决于您要执行的操作。 If C++App is working like a function, thus input -> C++App -> output and is not called very often then it makes sense to just call exec and spawn it. 如果C ++ App像函数一样工作,因此输入-> C ++ App->输出并且不经常被调用,那么仅调用exec并生成它就很有意义。

On the other hand, if C++App has to serve a lot of requests per minute, and also in parallel, then it makes more sense to build it as a daemon that can asynchronously handle all requests. 另一方面,如果C ++ App必须每分钟同时并行处理大量请求,则将其构建为可以异步处理所有请求的守护程序更为有意义。 (boost::asio can help you here) (boost :: asio可以在这里为您提供帮助)

Why? 为什么? Because a) communication via sockets it less expensive than spawning a new process everytime and b) because lets say you have 10 000 simultaneous requests, then the exec approach would spawn 10000 times C++App. 因为a)通过套接字进行通信比每次生成一个新进程都便宜,并且b)因为可以说您有10,000个并发请求,所以exec方法将生成10,000次C ++ App。 You can imagine that this could eventually suck up all your memory. 您可以想象,这最终可能会耗尽您的所有记忆。 In the daemon approach, you would just have 10 000 socket connections, which boost::asio can handle without any problems. 在守护程序方法中,您只有10,000个套接字连接,boost :: asio可以毫无问题地进行处理。

But be careful, the async approach definitely needs good engineering. 但是要小心,异步方法肯定需要良好的工程设计。 You need to write it in a way so that no requests blocks another requests and this can turn out to be quite difficult. 您需要以某种方式编写它,以使任何请求都不会阻塞另一个请求,这可能会非常困难。 So I would also consider this. 所以我也会考虑这一点。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM