So I'm making a chat app. I use ajax to check for new entry(message) in database every 0.5sec. If there is then display the message. Is that too much to ask the server? Im using a cheap shared hosting service. From my experience so far, half the time message is fast and smooth, the other time, especially during peak time, messages disappear and the ajax request fail half the time. Sometimes even connection to database itself comes back fail. I want to know if its me asking too much from the server or my server is bad I should consider changing. (or both)
You have 2 simple ways,
First is that using some cache mechanism like Redis cache to save last state of every user-chat and last received message id,date to get rid of checking db on every request.
Second way is using Web-Socket instead of client to server requests. In this method you establishing a connection between client and server then once a new message arrived you pushes the message to client directly.
If you want to resolve your problem without any external tool, My offer to you is the second way.
In this case I would probably recommend going with Web Sockets, seems like it fits your use case.
Look into http://socketo.me/
That being said I would look into upgrading your hosting from a shared account if you are wanting your site to remain performant under a larger load. Again really depends how many users you are trying to cater for.
Related
I was checking a part of my application in which I connect to elasticsearch host server and then I realized for every time the front-end sends an report request to my back-end I'm creating an instance of elasticsearch client class using the following code :
$elasticClient = ClientBuilder::create()->setHosts($this->setHostsParams())->build();
Since our application sends about 20 requests to the back-end by loading the first page, I was considering if PHP's elasticsearch library might be capable of optimizing the initiation phase, or if anyone has a better solution for this, or it might not be a big of a deal after all and it's not a real overhead!?
PS : I did some research with it and didn't find any resources covering this subject.
Sharing an object instance is already discussed here and elsewhere so I'm not going to go into that.
What I'd point out, though, is there there's an elasticsearch API called _msearch which enables you to send multiple search payloads at the same time and the system will respond after all the individual requests have resolved. Here's some sample PHP usage.
This might be useful if you need all your ~20 requests resolved at once -- though it may be useless if you defer some of those requests only after, say, a user scrolls down and what not.
My site checks the database for overdue reminders by making an AJAX request every 5 seconds. I've been told this is not ideal because of too many AJAX calls, one person said it's almost like DDOSing your own site if there are many people on with several tabs open etc.
The alternatives are using websockets or ajax-long-pulling. I can't use websockets because my shared hosting doesn't have that capability. Ajax-long-pulling is not ideal because of limited connections.
So a workaround I thought of would be to have a file on the server which simply stores a token. The browser reads this file via a hidden i-frame every 5 seconds, and if something relevant changes in the database the token is changed and this signals the browser to send an AJAX request to get the new reminders.
Would that be a feasible workaround to significantly reduce the load on the server since it's not making so many AJAX calls every 5 seconds since it's just reading the file instead?
"one person said it's almost like ..." - was that person the system administrator of the host where your site runs?
"because my shared hosting doesn't have that capability" - if writing lots of code is cheaper than switching web providers then you really need to look at your at the way you manage your hosting.
"Ajax-long-pulling is not ideal because of limited connections" - and you think the same problem would not apply to websockets?
You seem to be trying to fix a problem you don't know exists. And you don't seem to be in a position to evaluate whether any changes you make will have the desired effect.
After discounting comet and websockets, your only option for reducing the impact on the server is to reduce the frequency of polling. But your next step should be to get establish a capability to assess what impact the facility currently has on the server and how that changes if you change the behaviour. This can be rather tricky on a shared host - at best you're going to see a lot of noise generated by other tenants, but if you really were consuming a lot of resources, I'm quite confident that a competent hosting provider would be alerting you to this.
I've been working on sockets, generally in PHP for a while. Currently I have a PHP client for connecting to a chat server, and output every each data sent from server it's connected to.
To explain that in a wider matter, I accomplished this using flush() function in PHP to write out every each buffer waiting in the loop. Buffer reader is withing a while where the condition is the status of the connection socket. But this matters less.
Now to what I want to accomplish. I want to keep socket handling to server side and data from server outputted to client, via AJAX/jQuery. So far, my researches always returned me HTML5 WebSocket and node.js, however, I "have to" be real picky about this, as for users of this, my minimal dependency might be:
WinXP IE6 users(Already disables jQuery, even)
Users without JAVA/Flash installed
So I have to think of possibilities in this, which is why I can't use a Flash/Java backend or a new technology like WebSockets, and neither I want to handle server stuff in the client. I really hate to be stuck in old technology but for this it's a must.
As I was searching around, I found this one being as similiar to my needs.
Is PHP socket a viable option for making PHP jQuery based chat?
And to quick review the answers, they all point to one direction, PHP multi-process and memory eating. I know this is a minus, but it's the best I can take for now. But yet still, there'll be timeout disconnects for inactive connections within a certain delay, and extension of the delay if wanted. So I'm not much onto this one.
Secondly, the last answer pointing to "Ajax Chat Application Tutorial", I made an overall review but whoa, writing each line into an html file and re-including it each time, that is which I could do without using an extra file but, is it really necessary? Plus re-reading the file from server side, and re-importing the whole read file into document every each time, isn't that just worse for "both sides"?
Either ways that's about it, I wasn't able to come to a conclusion for a while, and it happened, here I am again. (:P) Waiting for your answers/suggestions/ideas, thanks by now.
Regards.
There is server software available that specializes in such matters. Is called a push server/service. There's for example APE (http://www.ape-project.org/); according to their website, it's compatible with all web browsers and they even got a demo chat there. I'd suggest you to go for that solution.
Short task description: I want one signed in user to be able to send an instant short plain text message to another signed in user. The solution needs to be easily scalable and not too resource demandinng in terms of bandwidth and server load (and $$).
The first idea was do client polling but this idea was quickly abandoned since it didn't meet scalability requirement. So, after that I went into research and came accross a number of concepts including sockets, node.js, xmpp. The amount of information is a bit overwhelming, so I was hoping for some advice to point me in the right directions. Hopefully something with readily available hosting solutions.
#epascarello:
thanks for quick response. I did, but not in detail. Before going in-depth into any technology, I want to be know that this is actually what I need.
Most of the examples concetnrate on instant chat but my requirements are somewhat different. I don't need every signed in user to see a message, but only one particular user, for whom it was meant, while there can be, say, 100 000 users logged in...
#Saeed Neamati:
thanks! Yes, I pretty much understand the two client-server communication options and have come to the conclutions that the pulling is a no-go. What I am trying to find now is the most scalable (that's the main prerequisite) and (hopefully) easy to implement push option. For instance, the socket option is relatively easy but it seems like it's not going to scale well due to server overload (or am I wrong). The node.js (at least by concept description) should be better at that, but I wanted to get some confirmation to this assumption. With xmpp - I'm not even sure how relevant it is to my task and how to approach it.
#andyuk:
Andy thanks, yes socket.io is also something that I came accross while doing research. As far as I understand it requires a server module that needs to run on a host. Do you know if possible to run on any server or do I need to look for a specialized hosting company? THe socket.io site for some reason doesn't work on my PC (neither IE or FF).
Did you look at the source code of nodejs chat.?
Look, you only have two options for client-server communication. Either client starts a request (an HTTP request on the web), which is called pull model (like client pulls the request out of the server), and server responds to that, or server starts a response directly without receiving any request (an HTTP response on the web), which is called push model (like the server pushes the data out to the client).
What you described as polling is actually the pull model, and indeed it takes lots of resources from the server.
But on the other hand, when you want to use push model, your server should know the client. In other words, we know that HTTP (based on TCP/IP) is a stateless protocol, which means that after each request, your connection is closed, and server loses you and forgets about you.
If you want the server to know the client, you should keep the connection open. This is usually done via some HTTP headers like Keep-Alive and Connection.
But to do that you should read Comet Programming. However, this reduces your scalability, because more connections are kept open for a one-to-one map between connection and client (To understand this better, you can think of connections as doors of the server. The more you occupy the door as a client, the less other clients can use it).
Checkout socket.io. If web sockets isn't supported by the browser it will fallback to the next best transport technology.
There is even a chat example included in the source code.
As for your concerns about scalability, node.js is perfect for this due to it's event driven, non-blocking nature. Handling many open connections is one of Node's real strengths.
Plurk uses Node.js for their real time chat features and they support 100k+ users.
The challenge I'm facing is simulating a communication channel between two users of a website (e.g. gaming site), by using solely the technologies mentioned in the title.
Recently I've developed an online chess website where, the idea behind which was to give users the chance to play "live" matches too, not just lengthy games where you would make a move, then come back in 1-15 days to see if your opponent has responded. And the way this game engine works implies sending asynchronous requests to the server, both to update the info related to the game (in case you make a move), but also to verify if anything has changed (if you are waiting for the opponent to move).
To better explain this... the player whose turn it is (the browser of course) sends an async. request to update the game info, exactly when he makes his move. Meanwhile, the opponent sends PERIODIC requests, "asking" if anything has changed. If anything does change, the roles switch after the board updates.
Timers are behind the functionality of the engine, so my question to you is this: How would you go about simulating a com channel between two players, while trying not to put too much stress on the server, but also having games update as fast as possible, in order to maintain the "live" feeling to it. This is most important in 1 minute games (one of the available categories). Because in that case, requests NEED to take place VERY often (at least 1 second). But server responses could delay, there would be much stress on the server when having hundreds of games available at the same time etc... so you see my problem.
I look forward to hearing from you guys and picking your brain if you have any good ideas :)
Cheers!
Andrei
PS: In case you want to try it, the name is e-chess960.com
you would want to builds a socket server. node.js would be a good javascript based library to use for a socket server. each client would create a socket connection to the socket server, then when a client sends a message to the socket server, the socket server could immediately send the message back out to its subscribers without having to store it anywhere.
socket servers require socket access, which usually requires a vps instead of a shared server.
to make the solution work, you would require that the clients have the ability to create socket connections to your server. some browsers already can as part of html5, but not all yet. you could also use Flash as a way to create a socket connection.
What you actually want is not pulling the server every second, but instead keep a connection open and use the observer-pattern to distribute updates to the specific clients (in other words: push instead of pull). That way, your server resources will not get swamped by a new connection for every second and every client. A library to accomplish that is the Comet Library. Check out this nice tutorial for a sample application.