Socket.io for real time application
Would socket.io be the answer to this?
My answer is that socket.io / node.js is much better at dealing with real-time applications then PHP in the current form.
Then on the client side just have a function that calls the server socket script like every second?
In node.js you should not poll ask for the information, but instead you should have the information pushed(use redis pubsub or node.js events for that) to you. I advice you to have a look at a pubsub snippet from me on stackoverflow.com to explain myself a little bit. For the code to work you will need to install socket.io 0.6.x(0.6.18) because the latest socket.io 0.7.x has a slightly different API.
If so would there be a concern with this process if I ran it every second with regards to server resources?
Like I said before use pubsub semantics. You could for example use:
Would socket.io be the answer to this? Would I simply use socket.io with nodejs to create a server and emit events to query my db and return the results to display? Then on the client side just have a function that calls the server socket script like every second? Would that be the correct path to using socket.io? If so would there be a concern with this process if I ran it every second with regards to server resources?
If you want something realtime. The structure might be different.
First you need a middle man which help you communicate between browser and server.
Solution 1 : Request every 30 seconds to get realtime (Same as your current method)
Solution 2 : http Streaming. Once request has make to the server. Server can continue send response to browser. Due to many security browser issues, socket.io has born. Socket.io provide many method streaming, htmlfile stream,xhr request,flash...
Second, you need server to accept the connection and make a long poll services. Thank god ! socket.io has done this part for you.
Thirdly, the most important person ! That is data.
Solution 1 : Every request/trigger Call db or nosql database (SQLserver,mysql,Mongodb). Believe me ! Your db going die soon.
Solution 2: Messaging services. Services like Redis pub/sub, rabbitQ. It simply use subscribe and publish message in queue. It use particular protocol to publish message and they did not store message like db. So its can send message >100 k request /seconds ! Super fast.Wow ! Is it use this services can solved realtime solution ? Unfortunatly that a bit hard. Why ? Because use this kind of services you cannot store data, SQL query to customize your data need.
Solution 3 : In-memory process.Redis,memcached. Memory is super fast! You can store your final display results in memory. Memory can reached >100 k request/seconds.
Conclusion. To build a really realtime web application like facebook or tweeter. We need to apply all solution above + some cheat. Example, facebook friend notification. When you get friend news update, it use messaging services to publish alert to all friends (Max 5000 people).Because heavy publish will slow down message performance. After that cache (Memcached) the notification message to reduce calling db(mysql). How about we can get group message with over 1 million people ? Of course we dun publish to all over 1 million people. But we ask 1 million people to call our latest group messages which store in memory.
- Reminder : Scaling your server is important to achieve the realtime goal. Good luck !