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(a)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)