I checked how an increase in the size of the outputAggregationSize and outputBufferSize in Jetty.xml affects the data transfer speed.
   - outputBufferSize - set the size of the buffer into which response content is aggregated before being sent to the client. A larger buffer can improve performance by allowing a content producer to run without blocking, however larger buffers consume more memory and may induce some latency before a client starts processing the content.
   - outputAggregationSize - set the max size of the response content write that is copied into the aggregate buffer. Writes that are smaller of this size are copied into the aggregate buffer, while writes that are larger of this size will cause the aggregate buffer to be flushed and the write to be executed without being copied.
Documentation: https://www.eclipse.org/jetty/javadoc/jetty-11/org/eclipse/jetty/server/HttpConfiguration.html

The effect of changing these parameters depends on the maximum frequency of the CPU core. The default values are optimal for 3 Ghz and allow Jetty to transfer data from the collection up to 2.9 Gb/s, an increase in parameters on such a processor has no effect.
Doubling buffers on a 4.5 Ghz processor yielded the following results (wt=javabin):
  • 2.9 Gb/s - outputBufferSize=32768   outputAggregationSize=8192
  • 3.6 Gb/s - outputBufferSize=65536   outputAggregationSize=16384
  • 3.6 Gb/s - outputBufferSize=131072  outputAggregationSize=32768
  • 4.5 Gb/s - outputBufferSize=262144  outputAggregationSize=65536
  • 4.2 Gb/s - outputBufferSize=524288  outputAggregationSize=131072
  • 4.2 Gb/s - outputBufferSize=1048576 outputAggregationSize=262144
   Thus, according to the documentation, an unreasonable increase in buffers will negatively affect response latency and memory consumption per connection. And according to my tests the parameter should be kept in mind only when working on processors with a frequency of more than 3 Ghz with fast wt=javabin and after testing on own data and collections.
 
Best Regards,
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org

Reply via email to