Increasingly people expect websites to be interactive and respond to events in real time. This has been common for chat and instant messaging systems, but now we need to develop real time interaction into more and more web systems. We may need to push new items into a list, or update information as it changes in real time.

This is not the way web servers work, they serve content in response to a request and then they are done. It is static. But we need to make it persistent, or at least appear persistent.

Ideally I would use JavaScript frontend and backend with Socket.IO to create the bidirectional event-based communication between the browser and server.

This however is not always possible and we often have to achieve the same result in a LAMP (Linux, Apache, MySQL, PHP) environment.

There are two main options:

  1. A “long polling” approach where requests sleep on the server until a new data or changes are found, or until the timeout occurs (or approaches)
  2. A “heartbeat” approach where regular requests are made to check for new data or changes, eg every 5 seconds

There are pros and cons to each approach. A heartbeat involves much more network traffic, while long polling can use a lot of server resources as each connection to the server commits resources.

PHP long polling

The general approach is to check for new data and if none then sleep for a period of time before checking again and return data if found.

Normally has_event_happened() would be a database query to check for new data.

The front end implementation could be equally simple using jQuery:

In this example a new request is made every 5 mins (if no new data sooner) and new data is checked on the server every 5 seconds. In theory the latency is approximately 5 seconds since new data sent to the front end within 5 seconds of a change.

That’s about as simple as it gets so clearly you’d need to build in appropriate event management and error logging and reporting.

If you’re not careful Apache will quickly tie up all the “worker threads” and leave it unable to respond to other requests. In many cases this will rule out long polling as an option but with a bit of server setup tweaking it can be a viable option.


This approach is very similar to the long poll except that the sleep occurs on the client side rather than server side. With long polling new data will be sent to the front end once detected server side. With the heartbeat approach the front end waits between requests and the back end returns the result immediately as requested.

The front end using jQuery uses a timeout to wait 5 seconds between requests.

Again this is just about as simple an implementation as you can get. The latency of this example is effectively the same as the long polling example.

Regardless of which approach you use you should make sure do load testing and calculations to ensure your server resources are sufficient.

I generally use a PHP framework that allows AJAX requests to be as lightweight as possible to further reduce server load. AJAX requests don’t need any templating so I don’t instantiate a templating engine (such as Smarty, Mustache, Twig, etc).

Tristan Claridge on EmailTristan Claridge on LinkedinTristan Claridge on Twitter
Tristan Claridge
Web Developer at Claridge Media
Tristan is a full stack developer with over 10 years experience developing innovative projects using LAMP, jQuery, AngularJS, NodeJS, and others. He has started and operated a variety of businesses including building the software systems used by, or sold by, the businesses. Tristan grew up in Brisbane, Australia, and has a couple of degrees from the University of Queensland. Tristan now lives in Dunedin, New Zealand, enjoying world-class internet speeds and the beautiful country.