4 ms·
One issue with this approach is that the author is allowing users to start the background work, rather than putting it into a queue like he had been doing with
by zackham 17y ago
One issue with this approach is that the author is allowing users to start the background work, rather than putting it into a queue like he had been doing with his prior site. If his site gets slammed, this will be a problem, whereas with a queue he could set up his interface to let the user continue browsing the site while his/her work makes its way through the queue.
One nice find from the article is the link to the Flash implementation of websockets: http://github.com/gimite/web-socket-js http://github.com/gimite/web-socket-js
- transmit101 17y agoA queue would be a nice addition before the site goes live (it might be possible to employ a Redis list to do the job). I'd love to see how far NodeJS could cope without the use of a queue though. I'm still something of a NodeJS novice but I'd guess that reading/processing every chunk inside a process.nextTick() callback would cause more disk IO problems than memory ones. When I get the app running I might do some load-testing, the results would be very interesting.
- codexon 17y agoJust curious, but does that implementation use the native websocket if possible, and then falls back on Flash if needed? I am interested in such a framework.
- Derferman 17y agoYep, the framework checks if the WebSocket object is defined, and if not, defines a custom WebSocket objects based around flash sockets.