Dragos Vingarzan <[EMAIL PROTECTED]> wrote on 04/25/2007
03:00:46 AM:
> Hello Charles, David, Olivier,
>
> We at FOKUS, for a 3rd party :), just started about a month ago too,
> working on such tools for benchmarking. However, we took a different
> approach as we believe that there is a true value in having even a
> light-weight SIP stack in SIPp (regexp are great, but if you need to get
> a lot of info from messages, they might be less efficient, easy-to-use
> and safe than parsing one time).
There are others in my group (Erich in particular) who also agree that a
SIP stack might be the way to go. There is certainly more need for SIP
knowledge (e.g., the retransmission hash needs to be updated). It will be
interesting to see if parsing the message once does improve performance,
which I think there is a pretty good chance of happening; at least for
UAS-like scenarios which needs to extract many headers to generate the
message. I am a bit torn in that I think that one big performance
advantage of SIPp is that there is no SIP stack, and thus it can generate
quite a bit more load than if there were (e.g., if it were to maintain
full transaction state, etc.).
> Also we were very interested in the
> transport layer and overcoming the limits in the number of different
> opened ports (something that you need if you want do simulate hundreds
> of thousands of clients).
>
> So we took a bottom-up approach with the target of having the state
> machines specified in the XML files.
Can you post a sample of your new XML format?
> Also we were thinking about
> extending the XML files with more control and state options, things that
> probably David already did.
You might be interested in some of the changes I recently posted that
introduce the notion of numeric variables and conditional tests on those
variables into the XML file, thus allowing you to do simple while loops.
> Overall, I think that all these changes are too radical to be integrated
> just as that in the SIPp trunk. Charles, you did a great job of pushing
> patches so far. But I think that if David also starts doing the same, it
> will just be too much to handle. Plus that, at least some of our
> changes, will kill the simplicity and ease of usage of SIPp and many
> current users would be upset. And I haven't even considered the new bugs
> that will be introduced.
Yes, it is clear that a development branch or branches and some release
engineering is going to be required.
Charles
--
Dr. Charles P. Wright
Research Staff Member
Network Server Systems Software
IBM T.J. Watson Research Center
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
