[simonhf]

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]

bcrypt doesn't reply immediately. You could set it to require ~10ms of CPU grinding each time it checks whether a password is valid, for example. Having latency while work happens on another core or server shouldn't impact the total number of concurrent connections the server can handle, though - the benchmark should measure that, specifically.

Oh, also - the reads and writes to the bcrypt server will be really short, and could use persistent connections. Something like "$2a$07$8BzFlUuprZN4FSBpDx3ZAuPWOu4CZ3uv8Awa4EjAZhNmnIY59nh2e" -> "OK". And yes, it would increase the number of events, but a real server is probably going to be communicating with a database, memcached, etc. instead.

FWIW, this comment thread is getting buried deeper and deeper in my threads page - if you want to keep the conversation going, my email address is in my profile. Have a good weekend.