I have a node.js server that serves an interactive HTML page to the client browser. SO in this case, the client frontend page is not served from the Apache server but is served from node.js server.
When user perform some actions (i.e. create a wall post or comment), I am thinking of using one of the possible flow of operations to manage them, but I have no idea which one is better (in term of performance, scalability for large amount of users, and ease of implementation).
So these are my options:
OPTION 1:
Socket.io will send the message details to node server (which listens to a particular port). Message will be encoded with JSON.
Node receives the message.
Node will communicate directly to the mysql database. Input sanitization is performed at this step.
Node broadcast the details to the other users who are subscribed within the same socket.io room.
OPTION 2:
Socket.io will send the details to node server. Message will be encoded with JSON.
Node receives the message.
Node calls PHP using HTTP POST. The PHP controller will then handle the HTTP POST message and will save all the corresponding details to the mysql databsase. Input sanitization will be performed at this step.
PHP will notify node.js server via redis, let's say using a channel called "mysqldb".
node will subscribe to "mysqldb" channel, and will then broadcast the corresponding details to the users who are subscribed within the same socket.io room.
Can you advise me the advantage and disadvantages of the above 2 approach? Is there any better approach?
Counter questions:
How many steps are required for the same action in each of you options until everything is through?
Think about all the things that could go wrong / fail / break for each of the options?
How much easier would it be if everything is written in one language?
How much time could be saved if data is not passed arround between node, PHP, MySQL and redis?
How many software packages do you have to install and configure for each of the options?
Unless you have a very very specific reason to plug PHP into fully functional software stack and actually do not know why this question even was asked.
Short version: Option 1
Related
So I'm using http://socket.io with node.js and developing a chat to learn more about node.js
I use node.js to communicate with MySQL when users open the page.
But for bandwidth reasons I can't keep using MySQL for everything so I store a few variables in there. For example I don't want the user signed in twice, so I would store the socket ID for all users in JSON. If the socket ID already exists for that user (in node.js), then I would disconnect the socket.
This works fine, but let's say I wanted to disconnect a user, how would I go about doing that with PHP?
One option I've considered is maybe I update a table in the database with the required changes and then node.js checks that table every 60 seconds and does what it needs to do, then updates the table after the changes are completed.
Is that the best option or should I try to accomplish this with PHP? Obviously PHP would be more immediate -- but that's not too much of a concern for me.
It's quite simple:
Make sure your node.js code supports HTTP requests and not just sockets.
Add a route to perform any actions. For instance you could handle /api/disconnect/:userId which would do whatever you need.
In your PHP code, call the relevant URL using either file_get_contents or the cURL family of calls.
Of course, you want to make sure you have some decent security so that only your PHP script can call you webservices, otherwise you'd open the door to all sorts of attacks. In the short term, this could be done simply by only listening 127.0.0.1 and using that address to communicate.
Note that the title of your question does not actually match its text. You're not actually modifying the node.js code, you're just modifying the data it manipulates.
Not sure that I follow your description, however one thing that stands out is that you are considering modifying code using code. Don't. Self-modifying code (regardless if it split across separate components of a system) is a very bad idea.
If the socket ID already exists for that user, then I would disconnect the socket.
Exists where? Presumably in node.js.
While you could use the database to persist the data, I would try to inject the data directly into node.js from the PHP script. That eliminates the polling step. There is a question over how you re-populate the information into node.js after a restart, but that depends on a lot more information than you've provided.
I have a PHP application that is already up and running and we have to implement a chat messaging system in it. We chose to do this with nodejs and socket.io as it seems the most effective and one of the best documented. I have PHP handling all the DB stuff and node just doing what it's most effective at: nonblocking io to update the client side when a message is received real time (through rooms). I also have a token based authentication going on using jsonwebtokens.
Everything is actually running well now:
When someone sends a message
1. JS send an ajax request to PHP
2. PHP saves the message to the database
3. PHP returns a response
4. JS receives the ajax response and then emits an event to signal to the node to update the appropriate clients
5. Node emits an event to the appropriate clients to update their views: notif icons, creates a silly sound and what not.
What I'm worried about are in steps 4 and 5. Since the data that will be passed to node in these steps are in the client side, any rogue user can effectively make modifications to these data and potentially be able to trigger an update of a view of another user even if he is not the intended receiver. The obvious solution I that I can think of is to allow node to have access to the database and validate that only the legitimate recipient will receive the event trigger, but that defeats the purpose of separating the concerns of the PHP app and node. What is the standard way of handling such a situation?
After a bit of reading I've decided on using Redis because of its PubSub capability. Refer to this for anyone who has the same concern: Redis sub/pub and php/nodejs
i'm running a social network with a messaging and notification feature. each time a user sends a message or places a notification for another user, a row is inserted into a table news_updates with the details about the message or notification and all his friends are inserted into the news_seen table. (once the message is read, or the item related to the notification is opened, seen is set to 1, i'm doing this at the end of my callback function for my ajax request - i'm gathering all the newsitem_ids from all the news items, that are currently open and then i'm doing a big insert with all the newsitem_ids in it).
news_seen:
newsitem_id bigint,
user_id big int,
seen int DEFAULT '0'
at the moment, i'm running an ajax request every 3 seconds, to check the news_updates JOIN news_seen for news.
this turns out to be a huge server load now that i'm getting more and more users. i've been reading a lot about xmpp and the like and i think a push notification service would be great for my site.
the only thing is, i can't really decide on which way to go, since there are so many options.
also, i thought about creating my own system. i'm planning to do it like this:
create an xml file for each user on initial registration (and run a batch for the already registered users)
once a user sends out a news update (i have my own php function for writing them into the db), i include a small command to manipulate the xml file for the respective friends
instead of doing my 3sec ajax request, i'd establish a long connection to the xml file using jquery stream and in case changes were made since the last request, i'd do my usual ajax request that polls the data from the db.
instead of running my check_seen inside the ajax request, i'd insert all the new items into a global array, to be used by an intervaled function that tests if any item in the list is currently being viewed.
do you think this is a good idea?
To be honest I do not think I would implement your specification.
For example I would use a lighter data-model then XML. I would use JSON instead.
I would avoid touching the DISC(database) as much as possible(slow).
Doing two requests instead of one(long-polling/polling). I would try to avoid this.
I would probably try to avoid wasting CPU-time by not using interval functions, but only calling function when needed. I would probably use something like REDIS's pubsub.
Polling / Long-polling is (most of the times) a bad idea in PHP because of blocking IO. I found an interesting project named REACT which I believe does non-blocking IO(expensive). I have not tested this(the performance) myself, but this could be an option.
For XMPP you will have to install additional software. I for instance liked Prosody for it's easy installation/usage. Then you would need to have a look at BOSH. For your bosh client I would use strophe.js or JSJaC.
I would probably use something like socket.io, Faye or maybe vertx.io instead, because it would scale a lot better.
I am looking to create a Web Chat system using PHP, MySQL and JavaScript.
Currently, I am storing messages in a MySQL database with an incremental ID (Yes, it is indexed), a timestamp, the sender, and the message itself. I am then using AJAX to query the database every 500ms, seeing if there are any more recent messages than the last one received. However, I have a feeling that this is probably horribly inefficient as it will result in a large load on the MySQL server when multiple users are online. Having looked around a bit on Google and on here, everything seems to point to this way of doing it.
My question: is there a better way to do this? Any tips on how to reduce the load on the server would also be welcome.
I'm using PHP 5.3, on an Apache webserver, so libraries or plugins compatible with those would be fine.
EDIT:
Forgot to mention in the original post, but I'm not worried about supporting IE or other outdated browsers.
Potentially viable basic approach:
Cache your 50 most recent messages in memcache. Reset this whenever a new entry is added to the database. When new users connect, serve them these 50 messages to populate their chatroom.
Use a third party service like http://www.pubnub.com/ to send messages to your clients. Whenever a new message is sent to your chatroom, send it out on pubnub. Your server code will do this after writing to your database successfully.
notes: I'm not affiliated with pubnub. You don't need to use 50 messages above either. You don't even have to give them any messages when they connect depending on how you want to set it up. The point is that you want to avoid your users reading from your database in this case - that model isn't likely to scale for this type of application.
Ideally, an evented environment would be ideal for this kind of app. The LAMP stack is not particularly well suited.
I would recommend using this library, Pubnub. Pubnub is an easy way to send radio signals via javascript, or any TCP language (such as PHP) - and javascript instantly recieves the sent messages.
In PHP, you could simply have it save to your database - then use Pubnub's PHP API's to send the message to everyone else on the page.
If your familiar with Html, Javascript, and PHP - it can be fairly easy to learn. I would recommend it.
You are asking about a web chat system specifically built in PHP, MySQL and HTML with JavaScript. There are many options including Pre-built solutions: http://www.cometchat.com/ and http://www.arrowchat.com/ which all have chat comet services powered by a cloud offering like http://www.pubnub.com/ with options to host it yourself. See more about CometServices http://www.cometchat.com/cometservice/third-party-alternatives where you compare the service providers. There are several more options, however I recommend starting there. If you needs something more simple, like HTML and JavaScript only solution, you can check out http://www.pubnub.com/blog/build-real-time-web-apps-easy which is a blog about building real-time web apps easy with an example chat app in 10 lines of JavaScript Code. The solution Cuts Development Time by providing full Cross Platform for all browsers and mobile devices.
You should look into ajax long polling, in a nutshell this a simple ajax call but will not return a result from the server if there is no new data. You just do a simple loop on the server side until new data will be available then return it. Of course you have to stop this eventually if there's no result to send to client after a while (eg. 1 minute) then restart the call.
I suppose, that chat is too intensive for storage engines MySQL. Maybe, MEMORY table type will be ok, never used it. I spoken to several developers and everybody agree, that best option for chat is Memcache or even writing your own custom daemon (with memory-only storage as weel).
For client part you may read about short-polling, long-poling and web-sockets / sockets via flash/Java object.
using AJAX to query the database every 500ms
Is short-polling.
Sockets are a better solution than AJAX polling, however isn't much around about how you can integrate socket based chats with MySQL.
I have done a few tests and have a basic example working here: https://github.com/andrefigueira/PHP-MySQL-Sockets-Chat
It makes use of Ratchet (http://socketo.me/) for the creation of the chat server in PHP.
And you can send chat messages to the DB by sending the server JSON with the information of who is chatting, (if of course you have user sessions)
My setup: Currently running a dedicated server with an Apache, PHP, MYSQL.
My DB is all set up and stores everything correctly. I'm just trying to figure out how to best display things live in an efficient way.
This would be a live challenging system for a web based game.
User A sends a challenge to User B
User B is alerted immediately and must take action on whether to
Accept or Decline
Once User B accepts he and User A are both taken to a specific page
that is served up by the DB (nothing special happens on this
page,and they dont need to be in sync or anything)
The response from User B is a simple yes or no, no other parameters are set by User B, the page they are going to has already been defined when User A sends the challenge.
Whichever config I implement for this challenge system, I am assuming it will also work for instant sitewide notifications. The only difference is that notifications do not require an instant response from User B.
I have read up on long polling techniques, comet etc.. But im still looking for opinions on the best way to achieve this, and make it scalable.
I am open to trying anything as long as it will work with (or in tandem) to my current PHP and MYSQL set up. Thanks!
You're asking about Notifications from a Server to a Client. This can be implemented either by having the Client poll frequently for changes, or having the Server hold open access to the Client, and pushing changes. Both have their advantages and disadvantages.
EDIT: More Information
Pull Method Advantages:
Easy to implement
Server can be pretty naïve about who's getting data
Pull Method Disadvantages:
Resource intensive on the client side, regardless of polling frequency
Time vs. Resource debacle: More frequent polls mean more resource utilization. Less resource utilization means less immediate data.
Push Method Advantages:
Server has more control overall
Data is immediately sent to the client
Push Method Disadvantages:
Potentially very resource intensive on the server side
You need to implement some way for the server to know how to reach each individual client (for example, Apple uses Device UUIDs for their APNS)
What Wikipedia has to say (some really good stuff, actually): Pull, Push. If you are leaning toward a Push model, you might want to consider setting up your app as a Pushlet