Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism

Emmanuel Hugonnet
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (550 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism

jtgreene
Administrator
My complaint with the parallel API is that it makes it too easy. Just 16 characters are required to do some operation concurrently without thinking about the resource usage impact and whether or not the task at hand is even beneficial in parallel. So my fear is it will be over-used and create problems.

His point is basically right that a typical web architecture is structured to support many simultaneous users, and you therefore need to minimize the resource consumption of each action in the application. However, there are use-cases where it would make sense, such as cooperative computational applications.

I think the big problem for us will be if frameworks we consume start making haphazard use of the platform FJ pool, so once we move to 8 we likely need to audit this area.

On May 28, 2014, at 9:30 AM, Emmanuel Hugonnet <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism

Jonathan Halliday
In reply to this post by Emmanuel Hugonnet

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
> [hidden email]
> 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)
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev