WAMPv2/v1 performance

[Daniel Faust]

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?

[Daniel Faust]

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.

[Tobias Oberstein]

Hi Daniel,

Am 13.09.2014 23:26, schrieb Daniel Faust:
>
> 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

> --
> 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.