Does it make sense that jgroups raft through put is just 140/s?

[赵琦]

Hi,

I create an cluster with 2 node 1,2 with jgroups-raft. Node 1 send an message to node 2, when node 2 receive message then reply to node 1. The average package size is about 2k.

In this scenario, the performance is only 140/s. Does this performance make sense.

The following is the raft.xml config file.

<config xmlns="urn:org:jgroups"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">

             

        <UDP

         mcast_addr="228.5.5.4"

         mcast_port="${jgroups.udp.mcast_port:45588}"

         ip_ttl="8"

         tos="8"

         ucast_recv_buf_size="5M"

         ucast_send_buf_size="5M"

         mcast_recv_buf_size="5M"

         mcast_send_buf_size="5M"

         enable_bundling="false"

         max_bundle_size="64K"

         max_bundle_timeout="30"

         enable_diagnostics="true"

         thread_naming_pattern="cl"

         timer_type="new3"

         timer.min_threads="2"

         timer.max_threads="4"

         timer.keep_alive_time="3000"

         timer.queue_max_size="500"

         thread_pool.enabled="true"

         thread_pool.min_threads="2"

         thread_pool.max_threads="100"

         thread_pool.keep_alive_time="5000"

         thread_pool.queue_enabled="false"

         thread_pool.queue_max_size="10000"

         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"

         oob_thread_pool.min_threads="1"

         oob_thread_pool.max_threads="100"

         oob_thread_pool.keep_alive_time="5000"

         oob_thread_pool.queue_enabled="false"

         oob_thread_pool.queue_max_size="100"

         oob_thread_pool.rejection_policy="discard"/>

    <PING />

    

    <MERGE3 max_interval="30000"

            min_interval="10000"/>

    <FD_SOCK/>

    <FD timeout="3000" max_tries="3" />

    <VERIFY_SUSPECT timeout="1500"  />

    <BARRIER />

    <pbcast.NAKACK2 use_mcast_xmit="false"

                    discard_delivered_msgs="true"/>

    <UNICAST3/>

    <pbcast.STABLE desired_avg_gossip="50000"

                   max_bytes="4M"/>

    <raft.NO_DUPES/>

    <pbcast.GMS print_local_addr="true" join_timeout="2000"

                view_bundling="true"/>

    <UFC max_credits="2M"

         min_threshold="0.4"/>

    <MFC max_credits="2M"

         min_threshold="0.4"/>

    <FRAG2 frag_size="60K"  />

    <!-- <RSVP resend_interval="2000" timeout="10000"/>  -->

    <pbcast.STATE_TRANSFER />

    <raft.ELECTION election_min_interval="500" election_max_interval="1000"/>

    <raft.RAFT members="1,2" raft_id="${raft_id:undefined}" resend_interval="1000" max_log_size="1000000000"  />

    <raft.REDIRECT/>

    <raft.CLIENT bind_addr="0.0.0.0" />

</config>

Thanks,

Qi

[Bela Ban]

What do you mean by node2 replies to node1? Is the invocation done via 
RaftHandle? Do you have some sample code?

For a client request to return the request has to be committed by a 
majority (in the 2 node cluster this is 2), which means the request has 
to be
- sent to the leader (if the node is not the leader)
- the leader writes the request to its log
- the leader sends the request to the follower(s)
- when the leader gets a majority of OKs from its followers (and 
itself), it commits the request (another write to the file system)
- the leader then sends the response to the caller, unblocking the caller

So, yes, the 140 reqs/sec could be feasible if you only have 1 thread 
invoking RaftHandle.set(). However, performance should increase if you 
have multiple threads or use RaftHandle.setAsync().

--
You received this message because you are subscribed to the Google Groups "jgroups-raft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jgroups-raft+unsubscribe@googlegroups.com.
To post to this group, send email to jgroup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jgroups-raft/0313b645-85e1-4d03-b57d-f29095a78d2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.