Performance difference in streaming data via Websocket vs normal outputstream
<p>We are streaming data from server to client due to a huge volume. It's basically a browser requesting for search results (these records are streamed to the browser). In the performance test, it streamed 150,00+ records in batches of 1,000. </p>

<ol>
<li><p>Option 1: use Websocket sending the batch of records via <code>org.springframework.messaging.simp.SimpMessageSendingOperations</code> which performed always within <strong>30-40 seconds</strong>.</p></li>
<li><p>Option 2: use normal outputstream, via <code>java.io.Writer</code> which Spring MVC injects in the controller method. However, it was performing poorly ranging from <strong>3-4 mins</strong>!</p></li>
</ol>

<p>The reason why we are considering option 2 is due to some inconsistent behaviour with Websockets (as admittedly we are using it for the first time). Hence, I coded our fallback to normal streaming via outputstream but the slowdown is not acceptable. Does anyone have any idea why there is a huge performance difference between the 2 options? Is it still possible to make option 2 faster (currently I will be playing around with the batch size)?</p>

<p>The snippet for the the batch writing process (where the app is reading the search results from a NoSQL input stream and writing to the brower's outputstream) is as follows:</p>

<pre><code>    public class DefaultStreamProcessor implements StreamProcessor {
       public void process(InputStream searchResponse) {
          try(BufferedReader br = new BufferedReader(new InputStreamReader(searchResponse))) {
              String line = null;
              while ((line = br.readLine()) != null) {
                 addToBatch(line);
                 if (isBatchFull()) {
//option 1: use websocket 
//simpMessageSendingOperations.convertAndSend("/topic/result/"+searchId, new ResultObject(getBatchAsMessage()));
//option 2: use normal printwriter
//writer.write(getBatchAsMessage());
                 }
              }
          }
       }
    }
</code></pre>