Goal:- Inserting messages in faster way to database.
I have integrated xmpp openfire one-to-one chat over my website.
I am using Monitoring Service plugin for storing messages into the database.
What i am facing is when user send a message from one user to another user at that time messages are stored in the database.
Now messages are stored, but i am facing issue of inserting messages late into the database.
I am loading messages via ajax call when user clicks on another user message thread but if the messages does not store in the database ofcourse it will not be returned in ajax call history.
I have done following configuration settings for Monitoring Service plugin.
I've find alternative solution of modifying Monitoring Service plugin's jar file and decrements inserting seconds but ultimately it will affect database.
Eg. Every minute 50 users send 10 messages at that time database may hanged.
Any help would be appreciated if i can store the messages into the database as faster way!
Related
I've implemented realtime chat in Websockets and it works just like a charm. I did it side by side with AJAX polling (which existed before), as I didn't want to remove AJAX polling support for older browsers, so although Websockets will be preferred, I am keeping polling as an option.
The way I have the websocket code set up is to:
Use Websockets to send the messages to the appropriate connections
Log the message in the database
The way the AJAX send works is:
Log the message in the database
The way the AJAX poll works is:
Check when user last retrieved messages for a room, and retrieve all messages since then
I have more of a conceptual question about how to get the two to work with each other. Assume I have User A and User B. If User A and User B are either both using AJAX polling or both using websockets, there are no issues whatsoever. It works as you would expect. But take the case when User A is using websockets and User B is using AJAX polling.
A → B
User A sends message via websocket
Chat message gets sent to all relevant connections. In this case, it just echoes back to User A, since User B is not using websockets.
Chat messages gets logged into database
User B requests new messages, and User A's message is sent back to him
B → A
User B sends message via AJAX
Message gets saved in database
?
This is what I'm hung up on. Websocket -> AJAX user messages work because the message ends up in the database where it can be polled by an AJAX user. But websocket users don't poll the database at all, so messages from AJAX users have no way of getting into the pipeline. Currently, websocket users don't see any messages from AJAX users. They only see them if they do a full page reload, at which point all messages get retrieved directly from the database.
What would be the appropriate method to allow some way for messages from AJAX users to get sent out via websocket to relevant websocket users? Basically, how can I communicate in the other direction?
The only thing I've been able to find on this subject is this slideshow - however, I'm not using longpolling, and I'm not entirely sure what it means by "providing that" to the websocket app. Does that mean put the onus on the websocket server to check for new AJAX messages? Is there no way to "push" from the AJAX script to the websocket server?
Thanks to ADyson for some ideas on how to approach this. This is what I ended up doing:
I have my JS clients ping the server every few seconds. For AJAX users, it's more frequent because they need to poll for messages. For Websocket users, they don't need to poll for websocket messages, so they poll every 15s to "check in". This has the benefit of functioning as an infinite loop essentially for each client, which is exactly what the idea requires.
What I did was essentially add a column to the messages table that keeps track of the message source: 0 for AJAX and 1 for WebSocket. Then, I modified the function that retrieves messages to take in an $ajaxOnly parameter. When I call this on an AJAX poll, it's false. For websocket polls, I call it with true instead. The result is for all rooms a user is in, it polls the DB and checks if there are any new AJAX messages. If there are, it sends them back to the client.
There are 2 caveats:
Messages will appear out of order. Websocket messages are relayed in realtime, so an AJAX message sent before a Websocket message could appear earlier to another AJAX user but later to other Websocket users.
This is not realtime. It's as slow as your poll interval, which in my case is 15 seconds for websockets since polls are very DB-intensive. AJAX polls are more frequent because they need to be to get any messages at all.
This isn't a perfect solution, but it does meet the goal of allowing AJAX messages to show up for websocket users in near-realtime. For me, I wanted to fully support AJAX and WebSocket, but AJAX is more for compatability and ideally most people will use WebSockets, so the fact that this isn't a great solution doesn't concern me too much, since it does get the job done.
If you were hoping for a realtime solution (like I was), you're going to be disappointed by this, but this is at least a workable solution so I've adopted it until something better comes up. You can make it near-realtime by increasing the frequency with which clients ping your server.
Simple solution:
When you save the message into the Datebase, push it to the Websocket Clients as well.
So I made a swift chat app that first requests a php file to load older messages from the mysql adatbase, and then I set up the real time chat with socket.io
Whenever a user sends a message it requests a php file which checks if the text is valid, then I do the encryption and store the new message in encrypted version in the database and I send the original message with socket.io to the correct user
What would be a good way to store user datas that are changing? (Nickname, profile picture)
The current swift array that holds the messages inself looks like this:
....| chatRooms
........| chatRoomId
........| messages(array)
............| userId
............| message
It would not be a good idea to store the nicknames with the messages I know, because the messages are getting cached and if the user quits & reloads the app, the cached nickname will show for older messages and the new one for the new messages.
Maybe I should make a userData array in the chatRooms? Or outside it? And save all the current talking-to user ids inside it then every minute request a PHP file to load nicknames?
What do you suggest guys?
Since you are already using an userId it would be obvious you need a new entity Users with the ID, nickname, profile picture etc...
If your objective is to limit queryes and load new profiles only when needed then you could broadcast a message from the server indicating which userId has changed data, since you are using websockets. This is to avoid reloading all the data every time (the problem is of course the profile pictures)
So I want to develop a chat system based on nodejs and socket.io, I have made a prototype and it works, the only thing that is stuck in my mind is how to store the chat messages in the database.
I guess is not a good idea to store a message when a user hits the enter button, because this is live chat you could have 1000 just from a user in 30-60 min.
The question is WHEN to store the data in the database, because I don't think that storing right away when the user hits enter will work on the long term?
The chat works on the same idea as facebook.
If you are not saving the messages at the moment, how do you plan to save them when you want to?
The messages sent have been delivered to the client and your server no longer has them, and you can't use the client to store them in a database.
You need to store the messages as the user sends them.
I have a website where users can register using their mobile number and the registered user get a text message confirming the registration. The page uses php. The mobile number gets stored as a variable $mobile.
The API for sending sms to the registered user is http://someurl/&message=[xxxx]&numbers=[xxxxx]
I want to execute the API in the background. I need to know a way to pass the number stored in $mobile variable to the API's url?
If the remote site responds fast you might try it synchronously: just call something like this:
file_get_contents(
sprintf('http://someurl/&message=%s&numbers=%s',
urlencode($message),
urlencode($mobile)) );
But usually it is more safe to perform such tasks independant from processing your registry step. Then you have to store that $mobile number somewhere. Probably you store the users profile data in a database. Also store a flag (marker) that the user has not yet been sent his message.
In addition you configure a cron job to call a script that does nothing but sending overdue messages on the server. It queries the database for any user profile that contains the flag indicating that the message has not yet been send and performs the same command as above.
The advantage: the user gets his feedback of registration right away, even when the sms gateway is down or busy. The message gets send a few seconds or a minute after the registration has completed. Such architecture is usually fast enough and much more stable.
I am creating a messaging system which have the following parts:
A form which send user message and upon submission of the form, PHP inserts the data into a MySQL Table called userMessages.
A PHP page which performs a MySQL Query select all from userMessages and displays all the messages.
The problem I'm having is making this messaging system have an INSTANT Message Functionality. i.e. I submit data from one form and it instantly appears on the user messages page WITHOUT having to manually refresh the page.
I do have temporary solution of refreshing the page every 20 second. But is there a way to update the messages page only at the moment a new message is submitted?
Pushing data to a web page is very hard, as Dan Grossman has said you will want to read that wiki article. AJAX polling every few seconds would be a good idea, if you don't mind a rather high server and database load. ama2 is also right - PHP is inherently not the best system for this, and a continuously running application server using, say, node.js, may be a lot more efficient.