Marshalling / RPC Performance

[werrenmi]

Hello together

A couple developers in our project told me about partial not so good performance with Errai RPC. In our application we have many views with lists (also more than one list per view).

I have created a plain maven archetype project from Errai 2.2.0 and native GWT 2.4.0 to compare and used the following dto class for the test:

{code}
@Portable
public class ModelClass {
          private ModelClass modelClass;
          private Long time;
          private String string;
     private String string1;
          private Double aDouble;
...
{code}

For the test i generated 100 association instances and the server just returns the same data back to the client.

Unfortunately the native GWT RPC invocation needed ~80ms to success and the Errai RPC ~130ms. We use Caller proxies for RPC.

I also played around with the errai.bus.buffer_allocation_mode , servlet implementations. No significant difference.

The test runs on the same JBoss AS 7.1.1.

Maybe anyone knows other possible points where i can try to improve the performance or to check?

Regards

Michel.

[jfuerth]

Hi Michel,

Thanks for bringing up this problem. Speed and efficiency are definitely among the design goals of Errai RPC.

Can you please open a JIRA for this issue? We will try to look into it during the Errai 3.0 development cycle (which is happening now).

Another possibility: if you don't need clients to handle exceptions thrown by the RPC service, you could try Errai JAX-RS. The client-side caller code would stay the same, but the server-side code would have to change a bit.

-Jonathan

[werrenmi]

Hi Jonathan

Thanks for your reply.

I have open an issue: https://issues.jboss.org/browse/ERRAI-559

Its created okay i hope

We use the ErraiBus also for broadcasts, because that JAX-RS would only partial solve this for us.

Regards Michel

[nva]

I found that especially large lists suffer from performance degradation. It's simply the nature of the beast: the errai demarshaller process will iterate through the list and then client processing usually includes at least one more iteration, if not more.

As a workaround you can broadcast properly formatted JSON structures as strings on the errai bus and load them into JSO-s on the client side. This speeds up things significantly, especially with complex objects.

[werrenmi]

Hi Valentin

Sorry for my late answer ... vacation

Thanks for the tip! I will try it.

Regards

Michel

[werrenmi]

Hello

I have also tried with JAX-RS. With the Errai Marshaller (JAX-RS Maven archetype) it takes 90 - 110 ms. When i activate Jackson on the client and Resteasy on the serverside ~200ms.

Regards

Michel

[csa]

Hi Michel,

If performance is a concern definitely go with Errai's build in marshaller. Jackson is not supported natively by Errai and involves a transformation step which can only add to the processing time. Have you tried any of these measurements with Errai 3? It would be interesting to see where we are at there. There's also a new 2.4.0.Beta1 release that you can try (it contains all improvements relevant to RPC).

Cheers,

Christian

[werrenmi]

Hello Christian

Now i have tested it. Both ... 2.4.0.Beta1 and 3.0-SNAPSHOT taskes a longer time (~250ms) with equivalent test data. I see there no really difference between 2.4.0.Beta1 and 3.0-SNAPSHOT.

Tomorrow i will make further tests with custom marshallers and tell you my results again.

Regards

Michel

[werrenmi]

I tried, but makes no sense, since with custom marshallers is it than a step more in the marshalling process.

Regards

Michel

[csa]

Hi Michel,

We have investigated this now and cannot reproduce the problem. We have used the exact same class you provided with 100 associations. We get the same performance on 2.2.0, 2.3.2 and 2.4. Actually, on 2.4 it's even slightly faster.

We have enhanced the bus-stress-test-demo to test this on JBoss AS 7.1.1.:

https://github.com/errai/errai/blob/2.4/errai-demos/errai-bus-demo-stress-test/src/main/java/org/jboss/errai/demo/busstress/client/local/StressTestClient.java#L89

You could try with this demo and see if you still experience slower performance on 2.4. Another thing to check would be the load on the client-side bus. Is your application sending a lot of messages while you're executing this RPC?

Do you see any other notable difference between your app and our demo?

Cheers,

Christian