I will say, I’ve never heard of this technology. So I’m basing my answer on what I’ve learned about it just now.
In the most simple case, it seems that SSE, at least when done with PHP, is basically a fancy long polling with easier client side integration. It’s up to your server code to tell whether the request is kept open as long as possible or returns immediately, or whether it returns one or multiple messages.
In any case, you’re probably going to run into issues with:
- Server side request limits preventing you from keeping connections open for a long time.
- Browser reconnections increasing hits usage.
- Entry processes, because connection being kept open require a server side process to hold the request. Even with a moderate amount of users, you’ll quickly run into the process limit which results in failing connections and suspensions.
- CPU and database usage. Even though you run one SQL query, you do need to setup a database connection, execute the query and process the result.
The fact of the matter is that there is no good way to do real time messaging in PHP. No matter what kind of client side implementation, it’s always going to end up with either a long running connection (which, with PHP, means long running concurrent processes) or rapid AJAX polling (which means a large number of script executions).
The fact of the matter is that the “right” way to do any kind of real time messaging is to run a server which can hold on to connections with a lightweight threading system, which PHP simply cannot do (not counting a few experimental server implementations). Spawning many PHP processes through a traditional web server to handle such connections is never going to be efficient.
A slow AJAX poll is probably the least bad option. And even then, you won’t be able to handle many users before getting suspended.