On 24.02.2017 09:23, Tôn Loan wrote: > Hi Steffen, > > Thank you for your useful advice. Actually, as you said, if I let > libevent handle the networking stuff within one thread, I wonder that is > there a bottle neck that happens when client sends a lot of messages to > four sockets?
Not from what libevent (or the underlying operating system calls) gives you. The bottleneck might be caused from your application, depending on how long you block the thread by processing the UDP packets. But depending on how the processing is done you may rewrite it and make the steps non-blocking/asynchronous as well. > I use multiple threads on different ports for the same service. Here is > my implementaton, > > Client A sends command X to thread 1 on socket 1234, then thread 1 will > receive command X and execute the command. > Client B sends command Y to both thread 1 and 2 on socket 1234 and 1235, > respectively. Two threads receive the command, but thread 2 send a > signal to thread 1, and wait. Thread 1 will execute the message, and > after it finishs, it send a signal to thread 2 to update the result of > command Y. By using this design, you actually have no benefit of using multiple threads. You process only one packet at a time and - in case - this is the reason for you bottleneck. As Jan already pointed out, create one that does the networking stuff (with libevent) and multiple others to process the packets to take advantage of multiple threads. It's a classical example of producers and consumers. The only advantage from your design is that the packets are received earlier by the application than in a single-threaded version. This might prevent running out of operating system buffers for udp packets but it does not make the client see faster responses. If you focus on responsiveness your approach gives you almost nothing. If you focus on "reliability", i.e. you try to avoid packet loss, then it might be valid. However, using UDP for reliable application is not a good idea at all. And as Jan already pointed out: benchmark/profile/measure your application: "premature optimization is the root of all evil" (or: "don't speculate. - benchmark!"). I'd follow Jan's advice to hack a small single-threaded (i.e. non-threaded) prototype with livevent that handles all four sockets including your main application logic. Depending if you are satisfied with its performance, you might choose between: a) process packets in multiple (not just one!) threads OR b) rewrite the processing to be as non-blocking as possible (my personal preference). (or combine a and b). Regards, Steffen *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
