Crossbar RPC performance with large payload

#1

Hi,

I’m trying to use Crossbar in a real-time application that requires sending large payloads (About 0.5MB each). I found out that Crossbar has a really good performance with multiple requests of small data packets but it seems that it’s not the same with large ones.

I got the same time difference (transmission delay) by using RPC or PubSub messaging patterns.

I’ve
written an example (using RPC) of a caller and a receiver, the receiver
prints the time difference based on the timestamp on which the package has been sent and the receiving timestamp. Is it normal to have 0,18s of
delay when transmitting a payload of 0.5MB? Is there anything I can do to reduce this time?

For instance by running the caller without arguments “python3 caller.py” (empty payload) I get:

Receiver count:1 difference:0.0008335113525390625
Receiver count:2 difference:0.0007576942443847656

whereas, launching “python3 caller.py -p” (large payload) I get:

Receiver count:1 difference:0.18456363677978516
Receiver count:2 difference:0.18334078788757324

Thanks in advance

caller.py (1012 Bytes)

config.json (2.2 KB)

receiver.py (481 Bytes)

0 Likes

#2

Faced similar issue with both java caller/receiver and js/java today.
The scenario is calling a simple function that returns 1-10 megabytes of data in a string.
After multiple tests, on average it takes 1 second to transmit 1024 kb of data. This is a very sad result.

···

On Tuesday, December 13, 2016 at 7:44:44 PM UTC+4, Hugo Caloto wrote:

Hi,

I’m trying to use Crossbar in a real-time application that requires sending large payloads (About 0.5MB each). I found out that Crossbar has a really good performance with multiple requests of small data packets but it seems that it’s not the same with large ones.

I got the same time difference (transmission delay) by using RPC or PubSub messaging patterns.

I’ve
written an example (using RPC) of a caller and a receiver, the receiver
prints the time difference based on the timestamp on which the package has been sent and the receiving timestamp. Is it normal to have 0,18s of
delay when transmitting a payload of 0.5MB? Is there anything I can do to reduce this time?

For instance by running the caller without arguments “python3 caller.py” (empty payload) I get:

Receiver count:1 difference:0.0008335113525390625
Receiver count:2 difference:0.0007576942443847656

whereas, launching “python3 caller.py -p” (large payload) I get:

Receiver count:1 difference:0.18456363677978516
Receiver count:2 difference:0.18334078788757324

Thanks in advance

0 Likes

#3

Hi, just as a matter of interest, is there much / any difference if you don’t yield in the caller?

0 Likes

#4

If you need to pass around large amounts of data for a response from an RPC call then maybe consider alternative means?

This kind of things seems large not particularly recommended practise even when coding locally, never mind distributed…

0 Likes

#5

Adam: absolutely! just for kick off transmitting a huge chunk like that makes running a “progress bar” more difficult - chunking the data is generally a more user-friendly solution … however if there is a performance issue in a certain circumstance, where there should not be a performance issue, it would be nice to identify and fix it … :slight_smile:

0 Likes