WAMPv2/v1 performance

#1

Hi there,

I’m kind of migrating an app where a backend runs on an OlinuXino Lime from v1 to v2. Migrating is not the correct term since I’m reimplementing everything. The OlinuXino talks via UART to an ATmega328, basically functions as a LED dimmer. There the WAMPServerProtocol registers a self.registerForRpc(self.factory.SerialProtocolInstance, “http://example.com/mcu-control#”), where the SerialProtocolInstance has a method decorated with @exportRpc(“sendSerial”). This sendSerial recieves RPC calls from clients and forwards the data to the ATmega328, but it also does a self.wamp.dispatch(“http://example.com/mcu#data”, { ‘line’: line.replace(’\n’, ‘’) }, exclude=[]) in order to sync all connected clients. Works as smooth as butter.

The new version of the backend subscribes to a topic, and the data for the ATmega328 arrives at that topic. In the topic handler I do three calls
self.serialProtocol.lineSend(line)
self.publish(‘com.myapp.mcu.event’, {‘hostname’: bc.hostname, ‘from’: ‘self’, ‘line’: line, ‘reflected’: data[‘reflect’]}, options = PublishOptions(acknowledge = True, discloseMe = True, excludeMe = False, eligible = [details.publisher]))
self.publish(‘com.myapp.mcu.event’, {‘hostname’: bc.hostname, ‘from’: ‘other’, ‘line’: line, ‘reflected’: data[‘reflect’]}, options = PublishOptions(acknowledge = True, discloseMe = True, excludeMe = False, exclude = [details.publisher]))

My problem is that v2’s performance is extremly sluggish. v1 is smooth, as realtime as it gets. v2 not at all, unless I comment out the two self.publish(…) calls, or just one of them, which only halves the problem, but it’s still as bad as a no-go gets.

Any idea what could be causing this?

0 Likes

#2

I’ve been checking out this issue a bit more, it’s a problem with the self.publish method in general
placing a
for i in range(1024):
self.publish(‘com.myapp.mcu.event’, {‘hostname’: bc.hostname, ‘from’: ‘self’, ‘line’: ‘led0:duty:’+str(i), ‘reflected’: ‘nothing’}, options = PublishOptions(acknowledge = False, discloseMe = True, excludeMe = True))

``

in the onJoin of the backend, or in any other place, has the same effect: this loop takes 3.5 seconds to execute. During this time no data is arriving at the router. after onJoin finishes, the data starts arriving at the router. removing the options reduces this to 2.7 seconds.

in contrast, in WAMP v1
for i in range(1024):
self.wamp.dispatch(“http://example.com/mcu#data”, { ‘line’: (‘led0:duty:’+str(i)).replace(’\n’, ‘’) }, exclude=[])

``

takes 0.8 seconds

in both cases the data starts arriving not until after the loop has finished.

···

On Saturday, September 13, 2014 1:27:25 PM UTC+2, Daniel Faust wrote:

Hi there,

I’m kind of migrating an app where a backend runs on an OlinuXino Lime from v1 to v2. Migrating is not the correct term since I’m reimplementing everything. The OlinuXino talks via UART to an ATmega328, basically functions as a LED dimmer. There the WAMPServerProtocol registers a self.registerForRpc(self.factory.SerialProtocolInstance, “http://example.com/mcu-control#”), where the SerialProtocolInstance has a method decorated with @exportRpc(“sendSerial”). This sendSerial recieves RPC calls from clients and forwards the data to the ATmega328, but it also does a self.wamp.dispatch(“http://example.com/mcu#data”, { ‘line’: line.replace(’\n’, ‘’) }, exclude=[]) in order to sync all connected clients. Works as smooth as butter.

The new version of the backend subscribes to a topic, and the data for the ATmega328 arrives at that topic. In the topic handler I do three calls
self.serialProtocol.lineSend(line)
self.publish(‘com.myapp.mcu.event’, {‘hostname’: bc.hostname, ‘from’: ‘self’, ‘line’: line, ‘reflected’: data[‘reflect’]}, options = PublishOptions(acknowledge = True, discloseMe = True, excludeMe = False, eligible = [details.publisher]))
self.publish(‘com.myapp.mcu.event’, {‘hostname’: bc.hostname, ‘from’: ‘other’, ‘line’: line, ‘reflected’: data[‘reflect’]}, options = PublishOptions(acknowledge = True, discloseMe = True, excludeMe = False, exclude = [details.publisher]))

My problem is that v2’s performance is extremly sluggish. v1 is smooth, as realtime as it gets. v2 not at all, unless I comment out the two self.publish(…) calls, or just one of them, which only halves the problem, but it’s still as bad as a no-go gets.

Any idea what could be causing this?

0 Likes

#3

Hi Daniel,

I've been checking out this issue a bit more, it's a problem with the
self.publish method in general
placing a
>
fori inrange(1024):
self.publish('com.myapp.mcu.event',{'hostname':bc.hostname,'from':'self','line':'led0:duty:'+str(i),'reflected':'nothing'},options
=PublishOptions(acknowledge =False,discloseMe =True,excludeMe =True))
>

in the onJoin of the backend, or in any other place, has the same
effect: this loop takes 3.5 seconds to execute. During this time no data
is arriving at the router. after onJoin finishes, the data starts
arriving at the router. removing the options reduces this to 2.7 seconds.

in contrast, in WAMP v1
>
fori inrange(1024):
self.wamp.dispatch(“http://example.com/mcu#data”,{‘line’:(‘led0:duty:’+str(i)).replace(’\n’,’’)},exclude=[])
>
takes 0.8 seconds

in both cases the data starts arriving not until after the loop has
finished.

dispatch() is doing a server-side injection into the broker. This is different from doing a publish() in a client, since the event needs to travel from the first client via broker to second client.

Regarding not receiving when doing publications in a tight loop: this is expected behavior, since the loop is effectively blocking the reactor from doing anything else.

In general: we are using Crossbar (= WAMP2 + AutobahnPython 0.9) in production without issues like excessive latencies or such.

If you think there is an issue, a convincing way to demonstrate would be if you create a benchmark test for AutobahnPython 0.8.15 in 2 variants using WAMP1 and WAMP2.

Cheers,
/Tobias

···

Am 13.09.2014 23:26, schrieb Daniel Faust:

On Saturday, September 13, 2014 1:27:25 PM UTC+2, Daniel Faust wrote:

    Hi there,

    I'm kind of migrating an app where a backend runs on an OlinuXino
    Lime from v1 to v2. Migrating is not the correct term since I'm
    reimplementing everything. The OlinuXino talks via UART to an
    ATmega328, basically functions as a LED dimmer. There the
    WAMPServerProtocol registers a
    self.registerForRpc(self.factory.SerialProtocolInstance,
    "http://example.com/mcu-control#
    <http://example.com/mcu-control#>"), where the
    SerialProtocolInstance has a method decorated with
    @exportRpc("sendSerial"). This sendSerial recieves RPC calls from
    clients and forwards the data to the ATmega328, but it also does a
    self.wamp.dispatch("http://example.com/mcu#data
    <http://example.com/mcu#data>", { 'line': line.replace('\n', '') },
    exclude=[]) in order to sync all connected clients. Works as smooth
    as butter.

    The new version of the backend subscribes to a topic, and the data
    for the ATmega328 arrives at that topic. In the topic handler I do
    three calls
             self.serialProtocol.lineSend(line)
             self.publish('com.myapp.mcu.event', {'hostname':
    bc.hostname, 'from': 'self', 'line': line, 'reflected':
    data['reflect']}, options = PublishOptions(acknowledge = True,
    discloseMe = True, excludeMe = False, eligible = [details.publisher]))
             self.publish('com.myapp.mcu.event', {'hostname':
    bc.hostname, 'from': 'other', 'line': line, 'reflected':
    data['reflect']}, options = PublishOptions(acknowledge = True,
    discloseMe = True, excludeMe = False, exclude = [details.publisher]))

    My problem is that v2's performance is extremly sluggish. v1 is
    smooth, as realtime as it gets. v2 not at all, unless I comment out
    the two self.publish(...) calls, or just one of them, which only
    halves the problem, but it's still as bad as a no-go gets.

    Any idea what could be causing this?

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com
<mailto:autobahnws+...@googlegroups.com>.
To post to this group, send email to autob...@googlegroups.com
<mailto:autob...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/autobahnws/4cea144d-db42-43f2-bc41-dd4602704f6b%40googlegroups.com
<https://groups.google.com/d/msgid/autobahnws/4cea144d-db42-43f2-bc41-dd4602704f6b%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes