<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">probably you subscribed to all events, and that's why you get so much<br></span><span style="font-size:12.8000001907349px">traffic on ESL connection? usually you need only specific events on<br></span><span style="font-size:12.8000001907349px">specific channels</span></blockquote><div>So, this mean there is chance that Event Socket Server (if event filters activated) works properly under highload (more than 50cps\300channels).</div><div>But after Kamil message, i falled in doubts... </div><div>As i understand, all events fires from FS to Event Socket Server, to minimize sending events (load) we need to filter it on FS side. In this case this FS send to Event Socket Server only required events. But i am not sure FS can filter it on it's side.</div><div>Second case - combine scripts handlers\curl modules with minimal events to Event Socket Server. This way is more complicated, but higload hopefull.</div><div><br></div><div>Kamil, you brought uncertainty into my thoughts! :))</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 1:38 PM, Stanislav Sinyagin <span dir="ltr"><<a href="mailto:ssinyagin@gmail.com" target="_blank">ssinyagin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">probably you subscribed to all events, and that's why you get so much<br>
traffic on ESL connection? usually you need only specific events on<br>
specific channels<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jun 11, 2015 at 12:33 PM, Kamil Nigmatullin<br>
<<a href="mailto:kamil.nigmatullin@gmail.com">kamil.nigmatullin@gmail.com</a>> wrote:<br>
>> In my view, and with my experiance it is not a good idea to be connected<br>
>> to FS all time.<br>
><br>
> Why? For whole call life control is good approach, because external<br>
> application know all information about call state and events. Or all events<br>
> external application, that receives and fires events to FS - this is my<br>
> way.<br>
><br>
> I thought this way as well. But when I tried to make stress test for 50cps<br>
> 300 concurrent, I had some unclosed calls. So then I moved almost code to<br>
> LUA. And only some commands like originate or reschedules of hangup left on<br>
> ESL. And I was afraid by how traffic between FS and external program is<br>
> huge.<br>
><br>
>> Better to use one time connection to execute some commands.<br>
><br>
> Hmm, this takes extra overhead for creation\closing connections. By the way,<br>
> for outbound socket connection FS use persistent connection or per event<br>
> connection ?<br>
> I thing this overhead is nothing comparing to all events that FS sends to<br>
> your external program.<br>
><br>
> By the way, for outbound socket connection FS use persistent connection or<br>
> per event connection ?<br>
> It is not by Event. In Inbound Socket I think it is the only connection you<br>
> have for all calls and events.<br>
><br>
><br>
><br>
> --<br>
> Kamil Nigmatullin<br>
> Tel: 77272323748<br>
> mob: 7 (707) 2517003<br>
> Skype: kamil.nigmatullin<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>