Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <ol> <li>Firstly, note that it's C*10K*. Don't concern yourself if you're less than about 100 (on a typical system). Even then it depends on <em>what</em> your sockets are doing.</li> <li>Yes, but keep in mind that <code>epoll</code> manipulation requires system calls, and their cost may or may not be more expensive than the cost of managing a few <code>fd_set</code>s yourself. The same goes for <code>poll</code>. At low counts its cheaper to be doing the processing in user space each iteration.</li> <li>Asynchronous IO is very painful when you're not constrained to just a few sockets that you can juggle as required. Most people cope by using event loops, but this fragments and inverts your program flow. It also usually requires making use of large, unwieldy frameworks for this purpose since a reliable and fast event loop is not easy to get right.</li> </ol> <p>The first question is, do you need this? If you're handily coping with the existing traffic by spawning off threads to handle each incoming request, then keep doing it this way. The code will be simpler for it, and all your libraries will play nicely.</p> <p>As I mentioned above, juggling simultaneous requests can be complex. If you want to do this in a single loop, you'll also need to make guarantees about CPU starvation when generating your responses.</p> <p>The dispatch model you proposed is the typical first step solution if your responses are expensive to generate. You can either fork or use threads. The cost of forking or generating a thread should not be a consideration in selecting a pooling mechanism: rather you should use such a mechanism to <em>limit or order</em> the load placed on the system.</p> <p>Batching sockets onto multiple epoll loops is excessive. Use multiple processes if you're this desperate. Note that it's possible to <code>accept</code> on a socket from multiple threads and processes.</p>
    singulars
    1. This table or related slice is empty.
    1. POThreading and scaling model for TCP server with epoll
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMatt Joiner
    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. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COMatt, I actually haven't written the TCP networking core yet. So I obviously don't see any reason to start with the "thread per connection" model if there is a better design pattern to consider first. Are saying that "select" is cheaper than epoll for low socket counts? Can you elaborate on the "cpu starvation" issue? I agree with the load balancing design point. And I have considered the multiple threads all blocking on accept.
      singulars
      1. PO
      1. USselbie
 

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