<div dir="ltr"><div>program/GF-DUMP: Shield ping processing from traffic to Glusterfs
Program<br><br>Since poller thread bears the brunt of execution till the request is
handed over to io-threads, poller thread experiencies lock
contention(s) in the control flow till io-threads, which slows it
down. This delay invariably affects reading ping requests from network
and responding to them, resulting in increased ping latencies, which
sometimes results in a ping-timer-expiry on client leading to
disconnect of transport. So, this patch aims to free up poller thread
from executing code of Glusterfs Program. <br><br>We do this by making
<br>* Glusterfs Program registering itself asking rpcsvc to execute its
actors in its own threads.
<br>* GF-DUMP Program registering itself asking rpcsvc to _NOT_ execute
its actors in its own threads. Otherwise program's ownthreads become
bottleneck in processing ping traffic. This means that poller thread
reads a ping packet, invokes its actor and hands the response msg to
transport queue.
<br><br>Change-Id: <a href="https://review.gluster.org/#/q/I526268c10bdd5ef93f322a4f95385137550a6a49">I526268c10bdd5ef93f322a4f95385137550a6a49</a>
<br>Signed-off-by: Raghavendra G <<a href="mailto:rgowdapp@redhat.com">rgowdapp@redhat.com</a>>
<br>BUG: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1421938">1421938</a><br><br>Patch: <a href="https://review.gluster.org/#/c/17105/">https://review.gluster.org/#/c/17105/</a><br><br></div><div>Note that there is only one thread per program. So, am wondering whether this thread can become performance bottleneck for Glusterfs program. Your comments are welcome.<br><br></div>regards,<br><div>-- <br><div class="gmail_signature">Raghavendra G<br></div>
<br>
</div></div>