[
https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz commented on WFLY-5822:
-------------------------------------------
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.
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-str...]
6.4.0.GA:
[
throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
---------------------------------------
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-str...]
6.4.0.GA:
[
throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)