[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/18/16 6:05 AM:
---------------------------------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time from *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
* Replacing the {{TransferQueueBundler}} with {{NoBundler}}: *99 us* down to *69 us*:
{noformat}
probe.sh op=TCP.bundler["no-bundler"]
{noformat}
* This clearly shows that threading and the bundlers are the biggest latency culprits (so far)
was (Author: belaban):
Findings:
* Disabling the thread pools in TCP brought the round-trip time from *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
* Replacing the {{TransferQueueBundler}} with {{NoBundler}}: *99 us* down to *69 us*
* This clearly shows that threading and the bundlers are the biggest latency culprits (so far)
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/18/16 6:04 AM:
---------------------------------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time from *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
* Replacing the {{TransferQueueBundler}} with {{NoBundler}}: *99 us* down to *69 us*
* This clearly shows that threading and the bundlers are the biggest latency culprits (so far)
was (Author: belaban):
Findings:
* Disabling the thread pools in TCP brought the round-trip time from *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-541) Invocation of hashCode on array in GeneralName.IPAddress
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-541:
--------------------------------
Summary: Invocation of hashCode on array in GeneralName.IPAddress
Key: ELY-541
URL: https://issues.jboss.org/browse/ELY-541
Project: WildFly Elytron
Issue Type: Bug
Affects Versions: 1.1.0.Beta5
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Internal class IPAddress from org.wildfly.security.sasl.entity.GeneralName invocates {{hashCode}} method on array. {{Arrays.hashCode}} method should be rather used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-540) Missing null check in ServerAuthenticationContext.NameAssignedState.isSamePrincipal() method
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-540:
--------------------------------
Summary: Missing null check in ServerAuthenticationContext.NameAssignedState.isSamePrincipal() method
Key: ELY-540
URL: https://issues.jboss.org/browse/ELY-540
Project: WildFly Elytron
Issue Type: Bug
Affects Versions: 1.1.0.Beta5
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In method {{isSamePrincipal(final Principal principal)}} of org.wildfly.security.auth.server.ServerAuthenticationContext.NameAssignedState null value can be assigned to variable {{name}}. It can result to NPE when null value is passed to following {{isSameName}} method. Check whether {{name}} is not null should be added before {{isSameName(name)}} calling.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/18/16 5:59 AM:
---------------------------------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time from *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
was (Author: belaban):
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/18/16 5:58 AM:
---------------------------------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
was (Author: belaban):
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*:
{noformat}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{noformat}
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/18/16 5:58 AM:
---------------------------------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
was (Author: belaban):
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*:
{code:java}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{code}
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/18/16 5:57 AM:
---------------------------------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*:
{noformat}
TP transport=channel.getProtocolStack().getTransport();
// uncomment below to disable the regular and OOB thread pools
transport.setOOBThreadPool(new DirectExecutor());
transport.setDefaultThreadPool(new DirectExecutor());
{noformat}
was (Author: belaban):
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*.
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months