Skip to main content

Re: Cost of @Asynchronous

No replies
Anonymous

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-configu...
>
> 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
>>

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
miluch
Offline
Joined: 2007-06-18
Points: 0

@Oliver
What do you mean by "Executing the same method more then ten times slowed
down the execution." ?

br Jakub

2012/10/3 Oliver Fischer

> 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.
>
> 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
>>
>>