Skip to main content

does multithread sip stack work for sipra

6 replies [Last post]
nijie8
Offline
Joined: 2005-06-09
Points: 0

hi,
I test with sipp in a better machine and caps remains the same. So i worder whether sipstack will be a bottleneck.
when i change sip stack to multithread and let sipra re-entrant. Dialog state will not go to terminate totally ,lots of them stay complete or null.
Can anybody explain why ?

By the way ,i change the activity judged by dialog ,so service can control the whole call stage. And will send activityend when dialog goes to terminate.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mranga
Offline
Joined: 2003-06-06
Points: 0

Do you have a multiprocessor machine? Otherwise making the sip stack multithreaded will not help because the requests all to into a queue and get consumed by the slee event loop. There is a lot of processing that happens in the SLEE - thread switching and Reflection do nothing to help performance. Indeed for a single processor machine, you will get the best performance by a single threaded stack and a single threaded SLEE.

I dont know why lots of them stay complete or null. You can delete them using dialog.delete() and they will be released.

What will help is to push proxy functionality into the SIP RA so that the SBB does not need to do all the processing - only that which is needed for specific services such as billing etc. This way the common function such as proxying are handled without needing to disturb the SLEE.

nijie8
Offline
Joined: 2005-06-09
Points: 0

i don't think so.
Before i use single thread to handle the slee events and only get 5 caps.
Afterwards i use 5 threads to handle the events, caps arise to 15.
That's nothing to so with multiprocess. Multithreads do work.

In fact I use b2b ua method to handle the entire call and how can i return them to proxy method. it seems impossible.

Of course proxy will be faster, but colorful service is more important than processing speed.

leondo
Offline
Joined: 2005-01-18
Points: 0

RA is not the bottle neck. The bottle neck is the tree cache accesses and its isolation level. You can have a better machine but the tree cache locks can actually degrade the multi-processing capabilities.

Please provide more contexts of what you are doing. Can you show your configuration of the run?

Leon Do

nijie8
Offline
Joined: 2005-06-09
Points: 0

ok, no problem

set the heaper size to fit your own machine. That will optimize the GC behavior and speed up.
I will try to find what 's the real problem with multithread sip stack.

this is added in run.bat for jboss

set JAVA_OPTS=%JAVA_OPTS% -Xms256m -Xmx256m -XX:SurvivorRatio=8 -XX:MaxNewSize=64M -XX:NewSize=64M

nijie8
Offline
Joined: 2005-06-09
Points: 0

ok,
i find the real reason is that eventObj is defined private in sipresourceadaptor.java and that prevent sipra re-entrant.
why not use temporary variable?

leondo
Offline
Joined: 2005-01-18
Points: 0

eventObj is a temporary variable. Have you check the new code recently?

Leon Do