<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 5:18 PM, Raoul Duke <span dir="ltr"><<a href="mailto:rduke496@gmail.com" target="_blank">rduke496@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jan 3, 2018 at 2:04 AM, Gregory Makarov <span dir="ltr"><<a href="mailto:gmakarov@gmail.com" target="_blank">gmakarov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I've done some load testing of Ejabberd and I see some strange results.</div><div><br></div><div>Ejabberd 17.08 on two node cluster with 4CPU cores (2.60GHz) and 8GB of memory on each node.</div><div>5000 online users in 250 shared rosters (20 users per shared roster). "roster" table is empty. Users change their presence approximately each minute (Away -> DND -> Away). </div><div>CPU usage on both nodes - approximately 350%.</div><div><br></div><div>Why CPU usage is so high? <br></div></div></blockquote><div><br></div></span><div>are you using the mnesia backend for shared roster or an SQL backend?  we have had problems with performance in the SQL backend outline here:</div><div><br></div><div><a href="https://github.com/processone/ejabberd/issues/1656" target="_blank">https://github.com/processone/<wbr>ejabberd/issues/1656</a></div><div><br></div><div>basically a lot of linear looping.</div></div></div></div></blockquote><div><br></div><div>PS - in my case I cheated and patched mod_shared_roster with a few assumptions that wouldn't hold up in the general case.  as explained in the above bug, depending on your dataset (number of groups) a lot of processing can go into determining if you have any "special" groups which IIRC are meta groups like @ALL.  since we didn't have any such groups we just patched that function to return nothing.  there is also a concept of groups having a "disabled" attribute but again our group list doesnb't contain any groups that can be disabled and therefore that processing is unnecessary.</div><div><br></div><div>RD</div><div><br></div></div><br></div></div>