Sounds good. How many lines of code do you think the password check test would be in node.js? If it's not too long then could you imagine doing the node.js version?
Hmmm... I'm confused because my node.js+net script also doesn't call setEncoding() and looks the same as your node.js+net script. The node.js+net+crcr script of yours is a nice optimization though on my test box it reaches 23,224 queries per second.
We are getting closer to open sourcing SXELua :-) It would be great if we could think up a better benchmark then the "Hello World" benchmark :-) What do you think about the suggestion described higher up in this thread?
silentbicycle, I like your idea. I wonder if it will be considered 'enough' by those who poopooed the "Hello World" benchmark? On a dual core or better box and assuming the bcrypt server replies immediately, I would predict that performance of the main server would halve. Why? Because the main server can only handle n events per second and by communicating with the bcrypt server we're doubling the number of read events which must happen within the same wallclock time. What I've found is that handling e.g. epoll events is slow compared to e.g. regular function calls or other IPC mechanisms on the same box. So the fastest way to do the bcrypt idea on a production server would be to use non-socket-based-IPC (e.g. shared-memory-based which is an order of magnitude faster than socket-based-IPC). Anyway, assuming we go with socket-based-IPC for the purposes of the comparison, what's the fastest way for the node.js program to maintain state and handle a pool of connections to the bcrypt server? It would be great if a node.js guru would take this on... and then I would take on the SXE and SXELua implementations. What do you think...?
silentbicycle, thanks, I updated the name as suggested.
So do you have any ideas for a more interesting benchmark program? Ideally it should be something which needs to keep state as you suggest and makes use of some kind of simple business logic, and is only a few hundred lines of code at the very most. What about a simple chat server which handles people and rooms? The benchmark might handle, say, max. 10k people chatting in max. 1k rooms. What do you think? Any better ideas?
mrb, thanks for the optimized version of the 'node.js+net' script. But what is difference with the original script? I copy and pasted your script and the queries per second result remains unchanged... so where does the 47% faster come from?
mrb, please note that the connections per second and queries per second are handled individually in the benchmark. So the connect handler should make no difference to the queries per second.
mrb, thanks for the optimized node.js code. I re-ran the benchmark and the queries per second increased to 23,224 queries per second... so I agree with the 30% faster but not your queries per second estimate (which math did you do? ~ 18k * 130% = ~ 23k or?). I will update the blog later to reflect this.