Use steed.each instead of plain loop

[behrad]

No description provided.

[mcollina]

tests are failing on all envs :/

[behrad]

Was editing this from github web editor, my mistake to remove defer(done) :)
Should now be fixed :)

[coveralls]

Coverage increased (+0.01%) to 92.434% when pulling 543f64a on adpdigital:master into 997de4a on mcollina:master.

[mcollina]

why are you using setImmediate there? And why are you calling done() before the actual callback is called?

[behrad]

Considering a huge (multi hundred thousands) list of forwarder callbacks, Does't setImmediate improve the iteration?Or steed does the same job?

[behrad]

We can bring next inside setImmediate right after cb returned. I just felt slow client callbacks should be don't care! so that we can report back from .publish ASAP!

[mcollina]

introducing setImmediate there will increase the total latency

[behrad]

will change this, thank you

[mcollina]

I still do not understand why using steed.each will be faster than just a plain loop.

[behrad]

I believe it is related to #148

[mcollina]

Solving this issue will be more complicated that a simple fix. You probably would want to have a queue-like thing. Using setImmediate will just create a very high load on the node.js process. A much easier solution is to reduce the cost of sending a message, i.e. move to mqemitter and aedes.

[behrad]

For the move, I'm waiting for aedes to be production ready, and I can help you anything around this.
For the queue, may we need that also in aedes?

[mcollina]

@behrad how many packets are you delivering? Aedes can deliver roughly 100k msg/s (mosca/ascoltatori 25k msg/s).

[behrad]

multiple hundred thousands is my target.
However with my own app logic on top of embedded mosca (haven't had enough time to separate that into multiple processes) it seems around 10K-15K in my local network, when 100K clients connected.
I'm also running many mosca instances (both horizontal & vertical=using pm2)!