Re: [wildfly-dev] Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism

Whilst disabling parallelism may be a reasonable default to stop less experienced users shooting themselves in the foot, I think it's a big (and ill advised) jump to go from 'using multiple CPUs for intensive per-request computation in the web tier is bad' to 'parallelism should be disabled'. The former advice is already borderline, as achieving latencies short enough to satisfy users can require utilising more than one core. 'maximise throughput' is a misguided appeal to the batch oriented model which can amortise fixed costs. There is no material benefit to that as web requests rarely share a useful amount of common work. Web tier throughput may actually be better if a single request is completed more quickly as a result of using multiple cores, since it will benefit from hot caches and release RAM faster, allowing more efficient GC. More generally, dispatching multiple remote requests in parallel can benefit from multiple threads without using excessive CPU use. In the web tier something that looks like an in-memory Collection can often be a lazy-load proxy over a db result set, remote K/V cache or such. In such cases pooled fork/join threads may block, not to mention endless hours of debugging fun with non-'thread safe' (sic) implementations like Hibernate's Session. On the one hand you want to dispatch independent remote requests in parallel as much as you can, whilst on the other you have to pay attention to the support or lack of it that is provided for that in the libraries you're using. For the foreseeable future we will be living in a world where some APIs have been retrofitted for parallel/async behaviour (e.g. servlets, collections) and some have not (e.g. JDBC/JPA). Best practice for gluing the two models together is not as simple as 'parallelism should be disabled'. It's important to carefully contextualise and guidelines and back them with empirical evidence. Do you have a link the presentation deck? I'm curious to see what use case(s) he benchmarked to reach his conclusions. Jonathan. On 05/28/2014 03:30 PM, Emmanuel Hugonnet wrote: -- Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill(Ireland)