Stasis optimization question

when trying to see the highest stasis backlog i get

Processor                                                               Processed   In Queue  Max Depth  Low water High water Low time(us) High time(us)
stasis/m:manager:core-00000012                                          786071133          0      62061       2700       3000          0     197759
stasis/m:cel:aggregator-00000011                                        310726913          0      12946       2700       3000          0    1685070
stasis/m:devicestate:all-00001b9e                                         3376815          0       4504        450        500          0     309266


will changing stasis.conf max_size help?

No. The options will have no impact on those, and there’s nothing you can do. Those subscriptions each have their own individual thread, and their implementations are written to be single threaded.

thank you for your reply !

do you think rewriting theses implementations to be multi threaded is it plausible is it worth it ?

will we get a better load like we got with taskpool?

shrug Possibly?

If it were reasonable to do without sinking a ton of time into it, though, we would have already done it. I’ll also add that if you throw AI at it, I’m not going to throw my time at reviewing the inevitable huge rewrites.

Oh, and before even going down that road a complete understanding of WHY it’s slow at handling things would be needed, which would then be used to inform whether multithreading things will actually do anything and the ramifications of it.

started looking in to manager as it is the biggest !

found in the general section there is a option disabledevents

if i understand correct if my client are only listening to
eventfilter(name(ContactStatus)) =
eventfilter(name(PeerStatus)) =
eventfilter(name(Newstate)) =
eventfilter(name(Hangup)) =
eventfilter(name(UserEvent)) =
eventfilter(name(QueueParams)) =
eventfilter(name(QueueMemberPause)) =
eventfilter(name(ParkedCall)) =
eventfilter(name(UnParkedCall)) =
eventfilter(name(ParkedCallTimeOut)) =
eventfilter(name(ParkedCallGiveUP)) =
eventfilter(name(QueueCallerJoin)) =
eventfilter(name(QueueCallerLeave)) =
eventfilter(name(QueueCallerAbandon)) =
eventfilter(name(AgentComplete)) =
eventfilter(name(AgentConnect)) =

i could black list all other events ,and i think this would bring down the queue
is there a reason not to do it ?

It should reduce the amount of work and time spent handling the relevant stasis messages.

i will test .
if it reduces by a lot i think it will be nice to implement eventfilter whitelist also for this section.
from my first look at at the code, it looks like a small change as gjoseph already built the infrastructure..

some bugs i found .

manager show events truncates event name after 20 characters, and there are duplicates like varset

also disabledevents is really hard to read all in one line

disabledevents = AGIExecEnd,AGIExecStart,AOC-D,AOC-E,AOC-S,AgentCalled,AgentDump,AgentLogin,AgentLogoff,AgentRingNoAnswer,Agents,AgentsComplete,Alarm,AlarmClear,AorDetail,AorList,AsyncAGIEnd,AsyncAGIExec,AsyncAGIStart,AttendedTransfer,AuthDetail,AuthList,AuthMethodNotAllowed,BlindTransfer,BridgeCreate,BridgeDestroy,BridgeEnter,BridgeLeave,BridgeMerge,BridgeVideoSourceUpdate,CEL,Cdr,ChallengeResponseFailed,ChallengeSent,ChanSpyStart,ChanSpyStop,ChannelTalkingStart,ChannelTalkingStop,ConfbridgeEnd,ConfbridgeJoin,ConfbridgeLeave,ConfbridgeList,ConfbridgeListRooms,ConfbridgeMute,ConfbridgeRecord,ConfbridgeStart,ConfbridgeStopRecord,ConfbridgeTalking,ConfbridgeUnmute,ContactList,ContactStatusDetail,CoreShowChannel,CoreShowChannelMapComplete,CoreShowChannelsComplete,DAHDIChannel,DNDState,DTMFBegin,DTMFEnd,DeadlockStart,DeviceStateChange,DialBegin,DialEnd,DialState,EndpointDetail,EndpointList,ExtensionStatus,FAXSession,FAXSessionsComplete,FAXSessionsEntry,FAXStats,FAXStatus,FailedACL,Flash,FullyBooted,HangupHandlerPop,HangupHandlerPush,HangupHandlerRun,HangupRequest,Hold,IdentifyDetail,InboundRegistrationDetail,InboundSubscriptionDetail,InvalidAccountID,InvalidPassword,InvalidTransport,Load,LoadAverageLimit,LocalBridge,LocalOptimizationBegin,LocalOptimizationEnd,LogChannel,MCID,MWIGet,MWIGetComplete,MeetmeEnd,MeetmeJoin,MeetmeLeave,MeetmeList,MeetmeListRooms,MeetmeMute,MeetmeTalkRequest,MeetmeTalking,MemoryLimit,MessageWaiting,MiniVoiceMail,MixMonitorMute,MixMonitorStart,MixMonitorStop,MonitorStart,MonitorStop,MusicOnHoldStart,MusicOnHoldStop,NewAccountCode,NewCallerid,NewConnectedLine,NewExten,Newchannel,OriginateResponse,OutboundRegistration,OutboundSubscription,ParkedCallSwap,Pickup,PresenceStateChange,PresenceStatus,QueueEntry,QueueMemberAdded,QueueMemberPenalty,QueueMemberRemoved,QueueMemberRinginuse,QueueMemberStatus,RTCPReceived,RTCPSent,ReceiveFAX,Registry,Reload,Rename,RequestBadFormat,RequestNotAllowed,RequestNotSupported,ResourceListDetail,SIPQualifyPeerDone,SendFAX,SessionLimit,SessionTimeout,Shutdown,SoftHangupRequest,SpanAlarm,SpanAlarmClear,Status,StatusComplete,SuccessfulAuth,TransportDetail,UnexpectedAddress,Unhold,Unload,VarSet,VoicemailPasswordChange,Wink

Be aware that the events still go to the manager subscription and still get handled, so that queue can still grow - even with disabledevents - because the events still have to be transformed into AMI and then comparison done.

correct and thank you

want to see the impact tomorrow
i think what i want to see is the max death and High time(us) should be lower that means it processed faster !

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.