If yes what tools have you used?

Comments

julien’s picture

julien commented

I haven't, but if you have some free time, i'll be happy to see the results.

gitesh.koli’s picture

gitesh.koli commented

Actually I m not sure how to :

We would have to run test with respect to
1. how many nodejs "user Authentication" requests can be handled by drupal at a time
2. how many "received messages" can be handled (this is not really that important atleast in my application)
3. Is how efficiently does server.js distribute the publish messages.

Not sure how to run an end to end test. I think it will have to be done in parts.

will surely post an update if we figure out how.

Suggestion are welcome ;-)

tizzo’s picture

tizzo commented

I know beejeebus did some load testing. He created a node.js script using the socket.io client library and spawned some 10s of thousands of connections and node.js handled it well. I'm not sure if the test was truly concurrent however, as a node.js script would be initializing all of those connections one after another (unless batches were created with spawned processes).

Anyway, hopefully he'll weigh in...

julien’s picture

julien commented

Made also some tests with siege, and it handles 200 concurrents with three different hit urls on my small laptop. The notifications are queued properly, but i'm not too sure if it creates a new socket on each hit.

tizzo’s picture

tizzo commented

You hit the site itself with siege? I'm betting that doesn't create a socket at all because siege doesn't really do anything with the response, right? That test will test node.js having lots of incoming messages for the queue and what happens when the heap starts getting huge, but won't test the socket.io part at all.

julien’s picture

julien commented

You're right, i was not able to see the socket id change in debug mode.

gitesh.koli’s picture

gitesh.koli commented

Just an update

I had 10 users login simultaneously and everyone had 2 / 3 browsers open.
I was pushing messages through a script to the nodejs server.

I expected all 10 users to receive all the messages but some users didn't.
I am sure that the nodejs server publishes messages. Because some people did receive all the messages.

Thoughts?

Browsers used : IE7 , Firefox, Safari

tizzo’s picture

tizzo commented

I wonder if it could be a firewall issue. Did those users ever get messages? I'm wondering if it was an issue with something about their machine.

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

i've created some simple load testing scripts here:

https://gist.github.com/1338991

it's not wired together automatically so:

- you'll need to set the values in settings to match up in both backend.js and client.js. you can also change things like the number of users, messages, the amount of connection shuffling etc. i found that if you make the numbers too big, the first thing that fails is the ulimit for open files, so you may need to adjust

- after starting the nodejs module's server.js, run the backend.js and client.js as separate node processes

feedback etc welcome, will move this onto drupal.org or github as a real repo once it's a bit more polished.

gitesh.koli’s picture

gitesh.koli commented

Actually it is not a firewall issue.

It is a browser issue. I did some more analysis on my application and found that IE had a problem with the connections.
Apparently it has a hard time keeping the connection alive and it keeps dropping and reconnecting it.

And during this time there could be message losses.
Firefox is a little better and had less dropped connections.

Chrome was by far the good one out of the three browsers and didn't loose connections at all.

Oh with IE you open two tab's to the same page with nodejs working on it second tab cannot keep the connection together.

I know this could be a problem with the socket.io component.

Anonymous’s picture

Anonymous (not verified) commented

gitesh, do you know which transport IE is using?

also, which version of firefox and transport? some versions of firefox disable websockets by default.

also, over here, #1329638: Lost Connection Notification, we want to look at handling lost connections better, to the extent we can.

gitesh.koli’s picture

gitesh.koli commented

Justin,

IE is using : jsonp-polling
Firefox / Chrome both use : websocket

What I have done is in the connection handlers I have set timeout which checks connection every 5-10 seconds.

Again I am using IE 7. We may want to test this in newer versions of IE.

Sorry for the late response but I can still help in testing this.