Databases
StackOverflow2013
Postsdbo
POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
    primarykey
    data
    text
    <p>I'm building a TCP-based daemon for pre-/post-processing of HTTP requests. Clients will connect to Apache HTTPD (or IIS), and a custom Apache/IIS module will forward requests to my TCP daemon for further processing. My daemon will need to scale up (but not out) to handle significant traffic, and most requests will be small and short-lived. The daemon will be built in C++, and must be cross-platform.</p> <p>I'm currently looking at the boost asio libraries, which seem like a natural fit. However, I'm having trouble understanding the merits of the stackless coroutines vs thread pool pattern. Specifically, I'm looking at HTTP server example #3 and HTTP server example #4 here: <a href="http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html" rel="noreferrer">http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html</a></p> <p>Despite all of my googling, I'm unable to fully comprehend the merits of the stackless coroutine server, and how it would perform relative to the thread pool server on a multi-core system. </p> <p>Which of the two is most appropriate given my requirements, and why? Please, feel free to 'dumb down' your answers regarding the stackless coroutine idea, I'm still on shaky ground here. Thanks!</p> <p><strong>Edit</strong>: Another random thought/concern for discussion: Boost HTTP server example #4 is described as "<em>a single-threaded HTTP server implemented using stackless coroutines</em>". OK, so it's entirely single-threaded (right? even after the parent process 'forks' to a child? see server.cpp in example #4)...will the single thread become a bottleneck on a multi-core system? I'm assuming that any blocking operations will prevent all other requests from executing. If this is indeed the case, to maximize throughput I'm thinking a coroutine-based receive-data async event, a thread pool for my internal blocking tasks (to leverage multi cores), and then an async send &amp; close connection mechanism. Again, scalability is critical. Any thoughts?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USTom
    1. USTom
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO*Query*: I think I understand "to scale up". What is "to scale out"?
      singulars
      1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
      1. USRobᵩ
    2. COSome people find the co-routine approach simpler to read/implement because the code reads from top to bottom. They are a better fit for streaming parsing because you don't have to worry about picking-up where you left off once you start consuming the stream again after a break in input.
      singulars
      1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
      1. USavid
    3. CO@avid -- thanks, I saw in the boost HTTP server example #4 how they did that with the request parser. It's very nice, no doubt, but I'm more concerned with performance than ease of coding/implementation. What are your thoughts on this?
      singulars
      1. POTCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines
      1. USTom
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload