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

Jonathan Halliday jonathan.halliday at redhat.com
Wed May 28 12:40:40 EDT 2014


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:
> Hi,
> Yesterday there was a presentation of the Java8 Stream API at the local JUG.
> According to the speaker (Paul Sandoz) parallelism should be disabled in webapps because :
> "...a machine serving web requests is usually sized/configured to maximize throughput. If web application code was using parallel streams
> then CPU resources would be consumed computing results that could otherwise be used to serve other web requests. A stream computation
> running on a fork/join pool will not block, it will try and go as fast as possible using as many resources as possible."
>
> What do you think ?
> Emmanuel
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)


More information about the wildfly-dev mailing list