Details

    • Type: New Feature
    • Status: Closed
    • Priority: 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

        Expenses

          Activity

          Hide
          ppolvorin@process-one.net 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
          ppolvorin@process-one.net 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
          cromain@process-one.net 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
          cromain@process-one.net 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
          ppolvorin@process-one.net Pablo Polvorin added a comment -

          initial approach to pubsub load testing from tsung

          Show
          ppolvorin@process-one.net Pablo Polvorin added a comment - initial approach to pubsub load testing from tsung
          Hide
          ppolvorin@process-one.net 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
          ppolvorin@process-one.net 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
          ppolvorin@process-one.net 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
          ppolvorin@process-one.net 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 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 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:

                Development