users@glassfish.java.net

Re: Cost of _at_Asynchronous

From: Jan Algermissen <jan.algermissen_at_nordsc.com>
Date: Wed, 3 Oct 2012 18:31:47 +0200

Oliver,

On Oct 3, 2012, at 2:01 AM, Oliver Fischer wrote:

> Hi Jan,
>
> you should have a look at this thread first:
> http://www.java.net/forum/topic/glassfish/glassfish/asynchronous-configuration
>
> I think it is still valid.
>
> Today I tried to improve the performance of one of our components at work by using @Asynchronous. My first impression is that the overhead of overhanding control to another thread pays only of if the actual work takes some time. In my case I got the impression that overhanding the control to another thread took the same time as the computation it-self. I played a little bit with the number of parallel invocations. Executing the same method more then ten times slowed down the execution. Furthermore I wasn't able to queue more then 250 parallel invocations without getting exception. So if you are going to use @Asynchronous you should take this into consideration.

thanks a lot - that resonates with my assumptions.

Jan


>
> Bye,
>
> Oliver
>
>
> On 02.10.2012 18:13, Jan Algermissen wrote:
>> Hi,
>>
>> JAX-RS 2.0 [1] comes with a new async feature that makes it possible to hand JAX-RS response creation to another thread, allowing the request handling thread to continue working on requests immediately.
>>
>> Combined with @Asynchronous this makes for pretty elegant code:
>>
>>
>> @Stateless
>> @Path("/")
>> class EJBResource {
>>
>> @GET @Asynchronous
>> public void longRunningOp(@Suspended AsyncResponse ar) {
>> executeLongRunningOp();
>> ar.resume("Hello async world!");
>> }
>> }
>>
>>
>> Now, handing control to a new or pre-created thread does not come for free. And I am wondering what factors to consider in order to estimate whether an async response will improve performance or capacity in a given scenario.
>>
>> I would assume that thread pool allocations and sizes influence this quite a bit. For example, when I configure large JPA thread pools so that every async JPA-backed response finds a free thread already waiting I'd expect improvements over synchronous response.
>>
>> Is this the right way to approach this? Or am I completely of track?
>>
>> Jan
>>
>>
>> [1] http://www.jcp.org/en/jsr/detail?id=339
>>