Skip to main content

who knows mobicents performance data

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

has anybody tested the performance of mobicents. I use sipp to test it and got 1 caps only. it seemed some bottleneck in the system.

Does multithread eventrouting make it better?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
fram
Offline
Joined: 2004-05-13
Points: 0

The main goal of mobicents is to provide an open source implementaion of JAIN SLEE, that we are using here at NIST as a research platform. Right now we do not have any performance test, your test is the first. I don't think that multithreading would help in a single processor machine, try to disable the log and the printf to screen maybe you can double the number of caps ;), can you please post the sipp configuration or command line you are using.
Thanks,
Francesco

Message was edited by: fram

mranga
Offline
Joined: 2003-06-06
Points: 0

After making the changes Francesco has noted below ( ie. disabiling printf to screen and setting the log level threshold in log4j.xml to WARN), also disable the tracing for the SIP Stack. Go to sipra.properties and look for the property gov.nist.javax.sip.TRACE_LEVEL and set it to 0. If you could, do report back what improvements you see after this.

Note that presently (in cvs), the log4j threshold is set to DEBUG as is the TRACE_LEVEL so you can expect it to limp along.

As Francesco has noted, this is an open source platform with the purposes of research, learning and experimentation for us at NIST. We want to produce a high quality and high performance platform for that purpose so we can produce realistic results from our work. We are contributing to it with that spirit.We would certainly be delighted if it were all that and more for the commuity.

Right now we need more hands to look at specific issues. We have not looked at perfomance tuning very much but we are indeed working on it. Specifically, we are loosening up the cache consistency model and looking closely at how multi threading has been implemented. Things should improve signifcantly over time. Maybe if you can find the time, it would be a good thing to identify where the bottleneck occurs.

Pitch in team! Consider this - if you have two guys building a car in a garage, there is no way to compete with a Ferrari.

Regards,

Ranga

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

sipp command as below
sipp 192.168.202.16 -i 192.168.202.150 -sf test10.xml -s 90000 -inf database1.csv -l 90 -r 3 -d 10

and how can i upload test10.xml and database1.csv?

I test latest version and got some error as below,it seemed something wrong with cache loading. it must be a bug:

2005-07-21 09:47:15,921 4458742 ERROR [org.mobicents.slee.runtime.EventRouterImpl] (Thread-182 EventTypeID[javax.sip.message.Request.INVITE#javax.sip#1.1], #16:) Caught an error!
java.lang.RuntimeException: Exception encountered while loading service
at org.mobicents.slee.container.service.Service.(Service.java:219)
at org.mobicents.slee.container.SleeContainer.getService(SleeContainer.java:2095)
at org.mobicents.slee.runtime.EventRouterImpl.processInitialEvents(EventRouterImpl.java:357)
at org.mobicents.slee.runtime.EventRouterImpl.routeTheEvent(EventRouterImpl.java:877)
at org.mobicents.slee.runtime.EventRouterImpl.access$100(EventRouterImpl.java:74)
at org.mobicents.slee.runtime.EventRouterImpl$EventExecutor.run(EventRouterImpl.java:152)
at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:88)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.RuntimeException: Failed to obtain object from cache: services:JAIN SIP Proxy Service-NIST-1.0/serviceID
at org.mobicents.slee.runtime.Cacheable.getObjectFromCache(Cacheable.java:305)
at org.mobicents.slee.container.service.Service.loadFromCache(Service.java:243)
at org.mobicents.slee.container.service.Service.(Service.java:199)

mranga
Offline
Joined: 2003-06-06
Points: 0

This bug has been resolved. Do try your gest again and let us know how it goes.

Ranga

fram
Offline
Joined: 2004-05-13
Points: 0

Can you please try the performance test with the latest changes.
Thanks,
Francesco

Message was edited by: fram

Message was edited by: fram

profcalc
Offline
Joined: 2005-01-20
Points: 0

Hi

I tried doing some SIPp runs with today's fixes. (Leon is out).

Basically, the same behaviour as before i.e after a few messages, the run gets blocked as the SIPp UAC is waiting on a 200 OK response indefinitely (to a BYE), which as far as the log goes has been "sent" by the Proxy on the corresponding ClientTransaction.

One thing I observed is that the CacheMap which is caching the convergencenames for the Sbb entities for the service keeps increasing.
The code I'm referring to is

if (name != null) {
boolean found = false;
----> Set childSbbs = service.getConvergenceNames();
Iterator si = childSbbs.iterator();

inside of EventRouterImpl.java. (line 360 in my copy)

Basically, it seems for each event (request or response) being handled by the Service, there is a SBB entity created and cached ? Is this because I have the initial-event-select variable set to "ActivityContext" ? It wouldn't take long before this Map has really ballooned up.

I didn't notice the event sequencing issue that Leon noticed. Again, one thing to note is that the SLEE is not blocked, its just the SIPp client thread is blocked. So for example, I could start up another SIPP client on another port and send messages to the SLEE (i.e until that too gets blocked).

Well, there is definitely something strange going on. Will post if I find more.

Chetan
Lucent Technologies