[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=13139829#comment-13139829 ] 

Richard Achmatowicz edited comment on WFLY-5822 at 12/10/15 11:07 AM:
----------------------------------------------------------------------

In general, there are two settings which affect creation of SFSBs: max-allowed-connected-nodes in the EJBCLient configuration, and the DeploymentNodeSelector.

max-allowed-connected-nodes determines the maximum number of Remoting connections that can exist between an EJBCLient and a cluster it is connected to. The default is 10. This means that if we have a cluster of 1000 nodes, all 1000 nodes will be known by the client, but only 10 of those nodes will have live Remoting connections open.  The client will only select nodes from those which have open connections (and so have an EJBReceiver registered). However, our cluster sizes are generally < 10, so this should not impact the test.

When a session is to be created for an application deployment, the client looks up all nodes which supports that deployment (getEJBReceivers(app, module, distinct) and gets back a list of open connections which support the deployment in the cluster. This list is then passed to the DeploymentNodeSelector which selects one node from the list. The default implementation is based in selecting a node at random.
  



was (Author: rachmato):
In general, there are two settings which affect creation of SFSBs: max-open-connections in the EJBCLient configuration, and the DeploymentNodeSelector.

max-allowed-connected-nodes determines the maximum number of Remoting connections that can exist between an EJBCLient and a cluster it is connected to. The default is 10. This means that if we have a cluster of 1000 nodes, all 1000 nodes will be known by the client, but only 10 of those nodes will have live Remoting connections open.  The client will only select nodes from those which have open connections (and so have an EJBReceiver registered). However, our cluster sizes are generally < 10, so this should not impact the test.

When a session is to be created for an application deployment, the client looks up all nodes which supports that deployment (getEJBReceivers(app, module, distinct) and gets back a list of open connections which support the deployment in the cluster. This list is then passed to the DeploymentNodeSelector which selects one node from the list. The default implementation is based in selecting a node at random.
  


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