[jboss-jira] [JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144287#comment-13144287 ] 

Richard Achmatowicz edited comment on WFLY-5822 at 12/31/15 11:54 AM:
----------------------------------------------------------------------

Just  based on a very preliminary check of the number of gets and puts in the test (my disk drive is full and I can't easily download these large logs in their entirety), I see the following stats on perf18 when I run the test for 3 iterations:

EAP 6.4.0.GA
# ISPN gets: 6776
# ISPN puts: 6843

EAP 7.0.0.DR4
# ISPN gets: ~ 700,000 (yes, seven hundred thousand)
# ISPN puts: 109

In other words, in the EAP 7 test, there are an abnormal amount of gets being made to the cache for what *should be* roughly the same number of client invocations arriving at the server as we are running (an updated version of) the same test on two server versions. I'm not yet tracking the number of client requests arriving at the server. There are also too few puts its seems.

This could be a problem with the test or a problem with the way EJB Client invocations are being handled at the server. Need to check arriving invocations next.

  


was (Author: rachmato):
Just  based on a very preliminary check of the number of gets and puts in the test (my disk drive is full and I can't easily download these large logs in their entirety), I see the following stats on perf18 when I run the test for 3 iterations:

EAP 6.4.0.GA
# ISPN gets: 6776
# ISPN puts: 6843

EAP 7.0.0.DR4
# ISPN gets: ~ 700,000 (yes, seven hundred thousand)
# ISPN puts: 109

In other words, in the EAP 7 test, there are an abnormal amount of gets being made to the cache for what *should be* roughly the same number of client invocations arriving at the server as we are running the same test on two server versions. I'm not yet tracking the number of client requests arriving at the server. There are also too few puts its seems.

This could be a problem with the test or a problem with the way EJB Client invocations are being handled at the server. Need to check arriving invocations next.

  

> Clustering performance regression in ejbremote-dist-sync scenario 
> ------------------------------------------------------------------
>
>                 Key: WFLY-5822
>                 URL: https://issues.jboss.org/browse/WFLY-5822
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 10.0.0.CR5
>            Reporter: Michal Vinkler
>            Assignee: Richard Achmatowicz
>            Priority: Critical
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-ejbremote-dist-sync/4/artifact/report/graph-throughput.png]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-ejbremote-dist-sync_noperf21/1/artifact/report/graph-throughput.png]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-ejbremote-repl-sync/3/artifact/report/graph-throughput.png]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-ejbremote-repl-sync_noperf21/2/artifact/report/graph-throughput.png]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)