Java Magazine, Sept/Oct 2018
ORACLE COM JAVAMAGAZINE SEPTEMBER OCTOBER 2018 47 the leading edge To set the thread pool size that will be used in calling the price service I use the formula from the documentation maximum requests per second at peak when healthy 99th percentile latency in seconds some breathing room Lets refer to the test results in Table 1 rows Requests per second and Holdings service response time 95th percentile to get the optimal number of threads When the price service is fast I get 94 requests per second Plugging that into the formula and multiplying by 0138 seconds 95th percentile equals approximately 12 threads When the service is slow the values for the formula are 987 requests per second multiplied by 1321 seconds which is approximately 13 threads So to give myself some breathing room I set the thread pool configuration to have 15 threads One of the benefits of using Hystrix is that the Hystrix API keeps statistics on Hystrix command execution how long the command took to process results whether the command timed out or not whether there were enough threads in the thread pool to service the requests and so forth An added benefit of using Hystrix is that it is easy to add a real time monitor to report how the system behaves These statistics can be used to allow real time monitoring and to drive the Hystrix commands behavior By default when you create a command Hystrix configures a circuit breaker that monitors command failures In my example command failures are the following The ticker price taking more than 1200 milliseconds time out to return An exception being thrown by the command The price service being down After a certain number of failures in a particular time interval which is again a configuration value that can be changed the Hystrix circuit breaker will switch from a closed state to an open state In the closed state which is the default state the Hystrix circuit breaker will allow
You must have JavaScript enabled to view digital editions.
