Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3.1
    • Component/s: Jabber/XMPP plugin
    • Labels:
      None

      Description

      Add to tsung the ability to inject load into a pubsub (XEP-0060) component.

      At first, four basic operations are required:

      • create a node
      • delete a node
      • subscribe to a node
      • push an event

        Activity

        Hide
        Pablo Polvorin
        added a comment -

        my first attempt is based on code that was already present in ts_jabber_common.erl,
        just added the way to configure it in js_config_jabber.erl.

        provide three messages types:

        <jabber type='pubsub:create' ack = "local" node = "relativePath|absolutePath"/>
        <jabber type='pubsub:subscribe' ack = "local" node = "relativePath|absolutePath" dest = "random|online|offline|User"/>
        <jabber type='pubsub:publish' ack = "noack" node = "relativePath|absolutePath"/>

        But now I'm having problems building a concrete scenario with those primitives.
        Basically, I need a set of publishers and a set of subscribers, easily done with two different session.
        The problem then comes, how do I know what UsersID are "publishers", so subscriber knows where to
        subscribe? (publishers put items in their own hierarchy).

        I think It can be done by having a global process keeping track of active publishers, and subscribers choosing one from
        that set.

        But I'm wondering if I'm thinking the whole problem in the wrong way, and there are better approaches to generate pubsub load?.

        Also, in the future it could be interesting to know the end-to-end delay, between the instant when the publisher put a new item, and when all
        subscribers receive the notification. But currently we aren't measuring this for any of the other cases neither (presence, muc, one to one messages).

        Show
        Pablo Polvorin
        added a comment - my first attempt is based on code that was already present in ts_jabber_common.erl, just added the way to configure it in js_config_jabber.erl. provide three messages types: <jabber type='pubsub:create' ack = "local" node = "relativePath|absolutePath"/> <jabber type='pubsub:subscribe' ack = "local" node = "relativePath|absolutePath" dest = "random|online|offline|User"/> <jabber type='pubsub:publish' ack = "noack" node = "relativePath|absolutePath"/> But now I'm having problems building a concrete scenario with those primitives. Basically, I need a set of publishers and a set of subscribers, easily done with two different session. The problem then comes, how do I know what UsersID are "publishers", so subscriber knows where to subscribe? (publishers put items in their own hierarchy). I think It can be done by having a global process keeping track of active publishers, and subscribers choosing one from that set. But I'm wondering if I'm thinking the whole problem in the wrong way, and there are better approaches to generate pubsub load?. Also, in the future it could be interesting to know the end-to-end delay, between the instant when the publisher put a new item, and when all subscribers receive the notification. But currently we aren't measuring this for any of the other cases neither (presence, muc, one to one messages).
        Hide
        Christophe Romain
        added a comment -

        pubsub will soon come default with flat namespace. if you use random node name like 0001 0002 ..... you don't need to know who is subscriber publisher
        all nodes will be open by default, so everybody can subscribe
        and people can only publish on node they created
        if you subscribe a non existent node, you get an error answer

        Show
        Christophe Romain
        added a comment - pubsub will soon come default with flat namespace. if you use random node name like 0001 0002 ..... you don't need to know who is subscriber publisher all nodes will be open by default, so everybody can subscribe and people can only publish on node they created if you subscribe a non existent node, you get an error answer
        Hide
        Pablo Polvorin
        added a comment -

        initial approach to pubsub load testing from tsung

        Show
        Pablo Polvorin
        added a comment - initial approach to pubsub load testing from tsung
        Hide
        Pablo Polvorin
        added a comment -

        Hi,
        the attached file contains the initial patch. It isn't well tested really, because of the problems to setup a test scenario
        that I mentioned previously. I didn't test yet Christophe's suggestions.

        To use it, you must add a global 'pubsub_service' option, like
        <option type="ts_jabber" name="pubsub_service" value="pubsub.localhost"/>

        To create a node
        <request subst="true">
        <jabber type='pubsub:create' ack = "local" node = ""/>
        </request>

        by specifying node="", tsung will try to create the "root" node for this user, /home/domain/user,
        if node="someNode", tsung will try to create /home/domain/user/someNode
        if node is absolute (starts with "/"), tsung will try to create it (/otherRootNode)

        To subscribe:
        <jabber type='pubsub:subscribe' node = "" destination="online|offline|JID"/>

        destination is used to address the node inside another user hierarchy IF the node address isn't absolute.

        To publish:
        <jabber type='pubsub:publish' node = "" size="ItemSize"/>

        Show
        Pablo Polvorin
        added a comment - Hi, the attached file contains the initial patch. It isn't well tested really, because of the problems to setup a test scenario that I mentioned previously. I didn't test yet Christophe's suggestions. To use it, you must add a global 'pubsub_service' option, like <option type="ts_jabber" name="pubsub_service" value="pubsub.localhost"/> To create a node <request subst="true"> <jabber type='pubsub:create' ack = "local" node = ""/> </request> by specifying node="", tsung will try to create the "root" node for this user, /home/domain/user, if node="someNode", tsung will try to create /home/domain/user/someNode if node is absolute (starts with "/"), tsung will try to create it (/otherRootNode) To subscribe: <jabber type='pubsub:subscribe' node = "" destination="online|offline|JID"/> destination is used to address the node inside another user hierarchy IF the node address isn't absolute. To publish: <jabber type='pubsub:publish' node = "" size="ItemSize"/>
        Hide
        Pablo Polvorin
        added a comment -

        Patch commited on revision 1024.

        Note: one more optional attribute was added to the pubsub:create request: 'node_type'
        It's only valid value is "flat". It porpoise is to allow the creation of nodes using the "flat" namespace provided by ejabberd.

        I'll create a simple scenario to add to the set of examples distributed with tsung. But meantime, here is the explanation of scenario we are using:

        Define two sessions "subscribers" and "owners".
        The owners session has a probability of 0. It only is executed by users explicitly asking it, whit the new <user..> tag on the <load> section.

        Using the <user ..> tag, we create as many publishers as desired, at the start of the scenario. The session of subscribers starts by waiting for a while before subscribing (to give enough time to all publishers to create their nodes).
        Both publishers and subscriber get the node names from a text file, using the file_server.

        Show
        Pablo Polvorin
        added a comment - Patch commited on revision 1024. Note: one more optional attribute was added to the pubsub:create request: 'node_type' It's only valid value is "flat". It porpoise is to allow the creation of nodes using the "flat" namespace provided by ejabberd. I'll create a simple scenario to add to the set of examples distributed with tsung. But meantime, here is the explanation of scenario we are using: Define two sessions "subscribers" and "owners". The owners session has a probability of 0. It only is executed by users explicitly asking it, whit the new <user..> tag on the <load> section. Using the <user ..> tag, we create as many publishers as desired, at the start of the scenario. The session of subscribers starts by waiting for a while before subscribing (to give enough time to all publishers to create their nodes). Both publishers and subscriber get the node names from a text file, using the file_server.
        Hide
        pellerin ugo
        added a comment -

        Hello
        I'm working on the benchmark of an openfire server with notification on 30000 clients by one publisher. I want exactly want to test what Pablo was saying : The time between a publication on a node and when all subscribers receive the notification. Is that possible now ?

        Show
        pellerin ugo
        added a comment - Hello I'm working on the benchmark of an openfire server with notification on 30000 clients by one publisher. I want exactly want to test what Pablo was saying : The time between a publication on a node and when all subscribers receive the notification. Is that possible now ?

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 39 weeks, 2 days ago

              Issue deployment