From what I understand after the number of max connections is exhausted the server will stop responding which is likely to happen on a live server with long-polling requests on index, will this also happen in a Litespeed server? From what I understand it is superior to vanilla apache and it will not spawn a thread per request.
Sadly node.js isn't really an option, I am trying to pull the newest results for users realtime once per 1-2 minutes.
it will happen on every server when You implement strict long-pooling
please look on websockets as it's the best way of handling thousands of users simultaneously (from performance side of view)
if You cannot use websockets try to implement reconnect as simple interval on which you abort current connection and establishing new one
You should look for a realtime web server, in your technology of choice, which support WebSockets as best-of-breed connectivity and falls back to HTTP-based solutions for older browsers and when there are tricky networks interfering with connections.
I'd recommend taking a look at the realtime web tech guide (which I maintain - and accept contributions to).
Related
I've been reading a lot on the subject of SSE and PHP, most of which seems to be advocating it as viable solutions for all sorts of things including chat apps. I have seen similar questions on this site but have not found a concise, definitive answer.
Is there something inherent in SSE which makes it way more server-friendly than AJAX short polling? Because the headers appear to be of very similar size. I am wondering if there is some kind of behind-the-scenes stuff beyond the headers that a noob like myself can't see e.g. some sort of connection recognition with each request/response? I know there are other factors involved where SSE prevails such as handling disconnections.
In terms of using it in a chat app scenario, ajax and sse appear to be doing the same thing. Neither of them seems to be able to perform long polling effectively with PHP. If I have User A and User B waiting on a PHP script that checks for new messages from the other user in the DB then sleeps for 3 seconds for say 10 loops, User A's new message cannot be inserted until User B has looped through the entire checking script, thereby rendering it absolutely useless (at least based on everything I've tried in the last 2 weeks!). I can get it working smoothly if I chat to myself and no one else is waiting on the checking script, but I've run out of things to talk about with myself and would really enjoy someone else being able to use it too.
So in a nutshell, given an Apache and PHP environment with WebSockets as not an option (due to shared hosting), is the only effective way to write a chat app, based on server burden alone, by short polling with one's choice of either AJAX or SSE, or is SSE definitely the superior option?
I would pursue WebSockets if the eventual traffic called for it and justified the web hosting upgrade.
(ALSO, as a side, is my premise off base regarding the long-polling scenario I described above where User A must wait for User B's loop to finish before he/she/it can perform the insert? Got me confused as to why that should be the case).
Kind of a long-winded, meandering question but hoping someone in the same situation can find this question and save themselves a lot of time.
Many Thanks!
Yes, SSE is a better option than AJAX, as AJAX polling is done on the main servers, like where most of the normal user traffic is to be hit. Whereas SSE polling is done on another instance which is made for it, so there will be no extra traffic on the main server. Please check Mercure (https://mercure.rocks/)
EDIT:
I mean to that, using SSE with platforms like Mercure would be a better option than AJAX. As AJAX will make a request to the main server. Which would increase the count of requests for the main server. Whereas we can distribute the network load using tools like the Mercure, in order to achieve the required functionality.
SSE can be thought of a thin API wrapper around the AJAX long-poll approach. It brings a standard API to something that was a hacky solution before.
something inherent in SSE which makes it way more server-friendly than AJAX short polling?
It holds the socket open. The pro of this is less latency (as soon as the server has the new information it sends it to the client, rather than waiting for the next client poll); the con is the extra resource usage (the socket, and the PHP process).
but I've run out of things to talk about with myself
Surely not. Have you tried starting a chat about if time is an illusion, and what came before?
with WebSockets as not an option (due to shared hosting)
SSE and WebSockets both hold a socket open. Shared hosting ISPs often go round closing sockets that have been open a long time (e.g. over 60s), unless they explicitly say they support SSE. The may also kill long-running PHP processes.
is my premise off base regarding the long-polling scenario I described above where User A must wait for User B's loop to finish before he/she/it can perform the insert?
I think it is off. The "A" in Ajax is asynchronous, meaning you can have multiple ajax/sse requests running at the same time. And on the server side you will have a distinct PHP process running for each request.
I will start developing a multiplayer card game in a few weeks and until then, I am doing research on the best techniques available. I will be using PHP+MySQL for server-side and JS/HTML5 for client side. The game will be also be played from mobile browser.
The gameplay of my game involves 4 or more users playing at a table, each having up to 30 seconds to take an action. There will be multiple tables available and an user can play at more than 1 table at the same time.
From my research it would seem easy to sync the client with the server by having the server push data trough SSE each time another player made an action. Then when the current player takes an action, the request data would be sent through XMLHttpRequest from client to server and then synced to other players through SSE.
Now from what I read, there is a big downfall to this because for each player that listens to the SSE process, a connection stays opened on the server, consuming a lot of memory.
The application that I will build is intended to support over 10000 players on a dedicated server with modern hardware(8core CPU,64GB RAM), with time. Some may say PHP is not good for this, but the debate here is how to use PHP to make this work.
The alternative to the SSE implementation would be to use Websockets (I am currently checking Ratchet and managed to set up the Chat server from the doc), but overall I have some dillemas which prevent me from taking a decision:
Websockets: When establishing the handshake, a connection stays open on the server too, same as in SSE, but I guess that this is a different type of connection which consumes less memory. Is that right? So websockets would be more efficient.
Any estimates on memory usage for both SSE and WebSockets? I read somewhere that each connection through SSE would consume around 20mb with APACHE and PHP. That's going to be 200GB for 10000 users (too much). I hope I am wrong.I dont know how much memory a socket connection would consume. An idle one I mean.
Will SSE consume more battery (on mobile phones) and will cause more web traffic than the sockets connection?
SSE: If an user will be playing at two tables, do I need to open two SSE processes (one for each table) or how do I tell the SSE process if I am requesting data for table1 or table2? Or I am forced to receive data for all tables at the same time? It wouldnt be a problem to receive data for all the tables that the user is now active at, but I am curious if there are ways of customizing this.
How about dealing with people that have unstable internet connection? Does websockets support automatic reconnection? Or this needs to be done manually from the client?
1) Do both WebSockets and SSEs keep the connection open?
Yes. Both WebSockets and SSEs keep the connection open as long as the server is configured to do so or connection is closed by either client or server. Because many times, servers are default configured to close the connection when it's idle for more than the time specified in configuration.
2) If both keeps the connection open then do both have same memory consumption and network overhead? Which one is lighter and faster?
First thing is that both seems to share same resources in terms of connection making because both has to handshake for the first time and check the heart beat by pinging and rest is a normal single TCP connection.
But there is an important point to note that Websocket is Bi-Directional and SSEs are Uni-Directional so even if a SSE connection is alive and you have to send some data from client to server then you will have to use some kind of XHR which will again create another connection to server. And creating connections is resource intensive. So, it seems like WebSockets is better at resource utilizing when this is about Bi-Directional like in case of above OP case of Card Game of multiplayers. And also this makes WebSockets more faster and Lighter than SSEs. SSEs are good when you just have to send data from server to clients like some Stock Market Prices, Game Scores etc.
3) If the your preferred choice is WebSocket then do we need to worry about URL Rewrite, Response Headers etc
I don't think so because if WebSockets are used with PHP then most of the time it is CLi based separate PHP Script twith a websocket connecting to something like ws://example.com:8092/websocket.php. So, I don't think there will be more to worry about URL Rewrite or response headers. And also as I think headers can be added/modified by PHP script itself if needed anyway.
4) Will SSE consume more battery (on mobile phones) and will cause more web traffic than the sockets connection?
I don't think SSE will consume more battery as compare to WebSockets. But yes it will definitely create more traffic to server because as mentioned above that SSE is Uni-Directional and each data from Client to Server will create another connection to server.
5) How about dealing with people that have unstable internet connection? Does websockets support automatic reconnection? Or this needs to be done manually from the client?
Well there are some techniques which can handle this part to reconnect in such conditions.
So a friend and I are building a web based, AJAX chat software with a jQuery and PHP core. Up to now, we've been using the standard procedure of calling the sever every two seconds or so looking for updates. However I've come to dislike this method as it's not fast, nor is it "cost effective" in that there are tons of requests going back and forth from the server, even if no data is returned.
One of our project supporters recommended we look into a technique known as COMET, or more specifically, Long Polling. However after reading about it in different articles and blog posts, I've found that it isn't all that practical when used with Apache servers. It seems that most people just say "It isn't a good idea", but don't give much in the way of specifics in the way of how many requests can Apache handle at one time.
The whole purpose of PureChat is to provide people with a chat that looks great, goes fast, and works on most servers. As such, I'm assuming that about 96% of our users will being using Apache, and not Lighttpd or Nginx, which are supposedly more suited for long polling.
Getting to the Point:
In your opinion, is it better to continue using setInterval and repeatedly request new data? Or is it better to go with Long Polling, despite the fact that most users will be using Apache? Also, it possible to get a more specific rundown on approximately how many people can be using the chat before an Apache server rolls over and dies?
As Andrew stated, a socket connection is the ultimate solution for asynchronous communication with a server, although only the most cutting edge browsers support WebSockets at this point. socket.io is an open source API you can use which will initiate a WebSocket connection if the browser supports it, but will fall back to a Flash alternative if the browser does not support it. This would be transparent to the coder using the API however.
Socket connections basically keep open communication between the browser and the server so that each can send messages to each other at any time. The socket server daemon would keep a list of connected subscribers, and when it receives a message from one of the subscribers, it can immediately send this message back out to all of the subscribers.
For socket connections however, you need a socket server daemon running full time on your server. While this can be done with command line PHP (no Apache needed), it is better suited for something like node.js, a non-blocking server-side JavaScript api.
node.js would also be better for what you are talking about, long polling. Basically node.js is event driven and single threaded. This means you can keep many connections open without having to open as many threads, which would eat up tons of memory (Apaches problem). This allows for high availability. What you have to keep in mind however is that even if you were using a non-blocking file server like Nginx, PHP has many blocking network calls. Since It is running on a single thread, each (for instance) MySQL call would basically halt the server until a response for that MySQL call is returned. Nothing else would get done while this is happening, making your non-blocking server useless. If however you used a non-blocking language like JavaScript (node.js) for your network calls, this would not be an issue. Instead of waiting for a response from MySQL, it would set a handler function to handle the response whenever it becomes available, allowing the server to handle other requests while it is waiting.
For long polling, you would basically send a request, the server would wait 50 seconds before responding. It will respond sooner than 50 seconds if it has anything to report, otherwise it waits. If there is nothing to report after 50 seconds, it sends a response anyways so that the browser does not time out. The response would trigger the browser to send another request, and the process starts over again. This allows for fewer requests and snappier responses, but again, not as good as a socket connection.
Is it possible to perform HTTP Push with Apache2+PHP? I've done some Googleing around and the only thing close to what i was looking for was a PECL Socket tutorial which didn't quite tackle what i was looking for.
My application at the moment has a basic read GET API, the client requests a read to the API once every 15 seconds. I think this is kind of silly as an open port that just sends data when there is data to send seems like a much better method. My client is written in .net.
Is this possible at all on these technologies? Or will i have to try and use java/comet, which at the moment i just don't have the resources / infrastructure readily available
More information on HTTP Server Push:
https://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
When deciding between different technologies to report events from a HTTP server to a client there are allways tradeoffs to make: 150 Clients polling every 15 seconds with a poll taking 1s will statistically tie up 10 connections, the same 150 clients with a server push technology will tie up 150 connections but with much less CPU.
IMHO Long polling has the best balance if used in combination with Apache/PHP, as it allows for the server to influence the clients, if these are in your control: If the connection count on the server goes too high, it can just return the longest running poll and send information to the client to not repoll immediately, but with some delay.
The details of the dedicated server (at the time the site starts) are as follows:
OS: Linux CentOS
CPU: Intel® Pentium 4 - 3.0 GHz
RAM: 2 GB
Storage: 2 x 120 GB hard drives
Bandwidth: 500 GB per month
The AJAX chat is customly coded. It runs by sending and receiving Javascript commands to and from the database, and then evaluating them.
The chat refresh rate will probably be somewhere around 250ms, although the answers here may change the decision.
If you want to implement browser-based chat application that's going to work on a relatively cheap server and be able to serve lots of users (say, 500 at a time) without crashing - your approach isn't effective.
Reasons: using DB to send JS to the clients who evaluate the code isn't really safe. It's also expensive. It also means that per every line of chat, you need to invoke the DB at least once.
That implies A LOT of I/O for the RDBMS.
If I were you, I'd check out Node.js.
Node.js allows you to write chat servers in JavaScript. The JS itself is not executed by the browser but by server.
It is extremely I/O efficient. It is also simple enough to allow a non-expert programmer to create proper chat apps.
Using php for chat server isn't a good idea. Polling can give too much unnecessary load to server and doesn't scale well. In my opinion you should rethink whole architecture.
Polling is bad for chat - use Comet (long polling) instead
With comet you will need fast HTTP server which can handle thousands of concurrent connections - use NGINX
PHP isn't good solution for chat app - process-like non-blocking solution is much better - look at Tornado and their chat example
From now on you must decide whether you need to scale - if not you can write single-thread server on top of tornado and store all data in memory - of course you will need to delete old unneeded data. If you need to scale choose fast scalable datastore like MongoDB - you'll have to poll database - but it will be single query for ALL clients connected to single tornado instance - not for every client
Facebook used (or still uses) this kind of architecture (using MySQL backend) for their needs