5

I was following a PHP-MySQL shoutbox tutorial that covered just sending and storing messages in the database. After I finished it, temporarily I chose to refresh the list of messages every 5 seconds or every time you send a new one using AJAX. But this would be too inefficient and server consuming(practically a low-intensity DDOS) in real life applications. So how do I refresh the list of new messages just when necessary? More precisely, how do I get notified that a new message was sent exactly when this happens so that I can display it?

chubakueno
  • 565
  • 4
  • 18
  • You may maintain a streaming socket open between the client and the server, so the server may directly send data back to the client. http://stackoverflow.com/questions/27425846/php-how-to-save-the-client-socket-not-closed-so-a-further-script-may-retriev – Adrian Maire Dec 17 '14 at 22:30

4 Answers4

7

A solution to your problem is called long polling, you'll find more information in this SO question.

The idea is to load information with AJAX as you currently do, but the server will not return a response immediately if there's nothing to return. Instead it will just keep the connection open for a predefined number of seconds before returning an empty response, or return as soon as a message becomes available. The max response time should be long enough to make it worthwhile, but not too long to risk a timeout on the client side - something around 20s should be fine.

Although this solution allows you to reduce the number of HTTP calls to your server, it just shifts the problem: you PHP script, while waiting for a message to be available, still needs to poll your database. If you're expecting moderate traffic, you'll be fine. But if you want to be able to seriously scale, you'll have to look for another solution.

The best solution would be to use a proper message queue instead of a database, such as Amazon SQS or IronMQ.

These will scale without limit, and will offer features such as long polling (not sure about IronMQ, but SQS definitely does).

Community
  • 1
  • 1
BenMorel
  • 34,448
  • 50
  • 182
  • 322
  • While I read it, i may tell you that it seems to me that we got serially downvoted for some reason(you, Cort Ammon, and me). – chubakueno Sep 14 '13 at 22:52
  • 1
    @chubakueno Let the haters hate :) – BenMorel Sep 14 '13 at 22:53
  • 1
    Have an upvote, for long polling actually being the most common, easiest to understand (and implement) and only solution to this problem based on the given architecture. Websockets are cool too, but difficult to understand and implement in PHP. Just make sure you have enough threads to keep the connections open (server config!). – opatut Sep 14 '13 at 22:55
  • Thank you for the excellent information and references. Actually, given that my server is quite restrictive and that I really don't expect a high traffic(my question was more in the possible optimization sense) I can see that the simplest and tidiest solution would be long-polling. – chubakueno Sep 15 '13 at 02:21
2

Getting notifications from a server side event is known as push technology. Typically these implementations take advantage of websockets to avoid the strain of polling.

Ratchet is a commonly used PHP WebSocket implementation that allows for data to be sent to the client using push technology. This will allow push notifications to be sent without polling or straining the server or connection pools.

Travis J
  • 81,153
  • 41
  • 202
  • 273
  • +1, websockets is probably the future, although for practical reasons I'm personally stuck with long polling for now. – BenMorel Sep 14 '13 at 23:08
  • @Benjamin - Websockets are very nice to use. You can always fall back to polling if they aren't supported by the client. – Travis J Sep 14 '13 at 23:11
1

I strongly encourage you to check Socket.IO project for client-side, a great live communication library that handles all protocols and solution based on visitor browser. This will solve your server-side problems too.

Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It's care-free realtime 100% in JavaScript.

  1. WebSocket
  2. Adobe® Flash® Socket
  3. AJAX long polling
  4. AJAX multipart streaming
  5. Forever Iframe
  6. JSONP Polling
-2

There is no way for a web browser to be notified by a server. HTTP is a pull based system. The entire purpose of AJAX is to fake being a push based system. If you need push, you need AJAX.

Cort Ammon
  • 10,221
  • 31
  • 45
  • 2
    This isn't true. There are ways for a server to send messages to a browser without the browser requesting them - http://en.m.wikipedia.org/wiki/Comet_(programming) – ryaanwells Sep 14 '13 at 22:57