Bug: high latency when sending uploaded chunks back to now.js client about now HOT 11 CLOSED

I ran node-inspector and used the V8 profiler to identify what the bottleneck is. As I suspected, all the time was spent JSON.stringify-ing the chunks (which were ~40kB each).

What's the fix? We have considered ditching JSON and sending pure binary over the socket. Your issue may get us to seriously implement that.

from now.

@sridatta, thanks for the debuging. Sending pure binary over the socket would result in a huge improvement in general and allow me to use now.js for this project as well. I hope this will get implemented.

from now.

It looks like something like BSON would be great. I am not sure whether it has been used before with socket.io, but it sounds very promising.

from now.

msgpack?

from now.

@dvv, looks interesting. Pgriess made what seems to be a pretty worked out library for it, see https://github.com/pgriess/node-msgpack

from now.

yep. for i fear workaround techniques used in socket.io won;t allow for pure binary data traffic.

from now.

Wow, msgpack is impressive. we'll do some tests and use that for serialization if it's as good as they are claiming.

from now.

Hmm. On my node.js setup JSON.parse is faster than msgpack.unpack.

from now.

@dvv, really? That's quite disappointing.

It's a true shame that Websockets do not allow binary transfer.

In that case I will limit my now.js usage to action and short message broadcasts, while for binary transfers (eg. files) I will respond to normal get requests.

from now.

I suppose you should first benchmark your setup. Plus, I guess chances are that for your static assets you'd still use a dedicated server

from now.

We've given this issue a lot of thought, and unfortunately there does't seem to be a simple solution.

The chunks take a long time because they have to be read into memory and then deserialized. Since the client-server communication is not a true tcp socket, we can't avoid that. Additionally msgpack isn't going to make anything faster because the binary has to be based64'ed to be transported anyways.

No good solution to this issue guys, closing. If someone comes up with any ideas, feel free to reopen

from now.