Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First thing first: verify that your hypothesis is indeed correct. You need to check:</p> <ol> <li>How much data is sent</li> <li>How much data is received</li> <li>How long does it take to send the data</li> <li>How long does it take to operate on the data</li> </ol> <p>HTTP works over TCP, which generally guarantees delivery, so even if it will take a long time, your server should be getting all the incoming information.</p> <p>That said, if you still want to make the process multi-threaded, I would recommend the following design:</p> <ol> <li>One thread like you have right now (<em>LISTENER THREAD</em>), that accepts incoming data.</li> <li>Another set of threads that will process the incoming data (<em>WORKER THREADS</em>).</li> <li>The listener thread will only receive the data and place it in a queue.</li> <li>The worker threads will dequeue the queue and operate on the data.</li> </ol> <p>Several notes and things to think about, though:</p> <ol> <li>Take care of thread synchronization - specifically, you need to protect the queue.</li> <li>Think if it matters which worker thread will get the data. If there are several chunks that need to be taken care of a specific worker thread, you'll need to address this problem.</li> <li>In some cases, if there is a very high load on the listener thread, the queue may become a bottleneck, or more precisely - the locking on the queue may become a bottleneck. In this case I would recommend moving into a model of N queues for N worker threads, and have the listener just pick one in a round-robin fashion. This will minimize the locks and actually since you'll have one reader and one writer you can even get away without a lock (but this is out of scope for that answer). </li> </ol> <p>Yet another option would be to use a thread pool. A thread pool is a pool of threads that are hibernating until they are needed. When the listener gets an incoming input it will allocate it to a free thread, or will enlarge the pool if needed; this way you don't have a queue, and your threads are optimally used. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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