The cost of switching threads is fairly negligible. If you are concerned about that level of performance then you are more likely to run into issues using the on thread per connection model. If you use the 1 thread per connection model you can only have that number of HTTP clients connected to your web server at any given time. However with the IO / Worker thread model you can have a low number of IO threads that accept a very large number of concurrent connections which then queue up all of the blocking requests for the workers to handle.The thread per request model is like going back in time to tomcat days where every webserver gets configured with hundreds to thousands of threads.However if you don't have a higher number of concurrent users it realistically shouldn't matter which way you choose. Just keep in mind the thread per request model doesn't scale as far when you have blocking work.On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in@gmail.com> wrote:My line of thought was, if every request requires a blocking DB call, why incur the cost of switching threads within a request, if I can instead simply increase the number of IO threads without any adverse effect.--
Chandra Sekar.SOn Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill@dartalley.com> wrote:This is exactly what the worker thread pool is built for why would you want to use the IO threads instead? The IO threads are for reading / writing to the socket of the HTTP request. All blocking operations SHOULD be dispatched to worker threads.On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in@gmail.com> wrote:_______________________________________________If I have a HTTP service where every request requires a blocking JDBC call, is it acceptable to increase the number of IO threads to a large value (say, 10*cores) instead of dispatching to worker thread pool on each request?Will configuring such a large number of IO threads lead to any adverse effect on throughput or latency?--
Chandra Sekar.S
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev