On 02/24/17 09:23, Tôn Loan wrote: [---] > 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? [---]
That reads to me like you're prematurely making assumptions about bottlenecks. Generally speaking -- as someone who learned to use profilers far later than I should have: The bottlenecks are often not where you think they are. I would suggest you try for the simpler solution first (write a quick'n'dirty prototype) and test a non-threaded version with a test-client with sends worst-case amount of data. Only if you notice that it's having trouble handling the workload you start looking into a threaded solution. But more importantly, if your program can't keep up, figure out why and work on the identified problem area. With regards to specific design suggestions, I have done sort-of what you describe (receiving command UDP packets at a somewhat high rate, and in my case processing them could sometimes take a while). What I chose to do after a little experimentation: I receive all UDP packets on the same thread and use queues (implemented as ring-buffers) to queue up the data for one or more separate processing threads. I.e. the "base thread" only receives data and dispatches the heavy work to other threads via queues. Getting these things right can take some trial and error; one thing I'd advise is to look at what mature projects do, because they have often (though not always) done all the mistakes and learned from them. -- Kind regards, Jan Danielsson *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
