0

I am trying to build a MySQL, PHP, Ajax based personal messaging system.

There is one table for all messages - msghistory, which looks like that

enter image description here

And another one for users' last message check date records - chkdate.

The system works like this:

When user signs into page, page fires Ajax autocheck. Ajax calls php in every 10 sec. PHP side checks for new messages by user id. At first checks chkdate, then checks msghistory: If there are no message after last check date then system will not notify user, else will notify about this

I think this way will load server heavily, if there are 1000s of users. I wonder if explained above way is optimal? if not, what do you think about this, which way is better?

halfer
  • 19,824
  • 17
  • 99
  • 186
Tural Ali
  • 22,202
  • 18
  • 80
  • 129
  • No, it is definitly not. – Eugen Rieck Feb 08 '12 at 02:16
  • 1
    On a more serious note: You should look at long polling - a short poll every 10 seconds is quite exhausting when user counts climb – Eugen Rieck Feb 08 '12 at 02:16
  • As I said: long polling. This means, that your client starts a poll, the server does NOT immediately return from the poll, but keeps it waiting for either an event (message) or a timeout (maybe minutes) this way the huge overhead of the HTTP transaction, PHP startup, etc. is incurred only much fewer times. – Eugen Rieck Feb 08 '12 at 02:21
  • @EugenRieck so I think increasing ajax interval up to 2 min will solve everything, right? – Tural Ali Feb 08 '12 at 02:24
  • It sure won't solve everything (most definitly not the Euro dept crisis), but it will help: 1000 users, 10 seconds poll = 100 requests/second just for the poll, might be 200 or 300 queries/second to the database. Same thing with 2 minutes=120 seconds makes 17 or 25 queries/second – Eugen Rieck Feb 08 '12 at 02:29
  • As I said: Long polling - this gives you **immediate** notification on a new message, but without the horrific overhead of a 10s poll. – Eugen Rieck Feb 08 '12 at 02:34
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/7445/discussion-between-trl13-and-eugen-rieck) – Tural Ali Feb 08 '12 at 02:35

1 Answers1

0

Long polling is a good idea. Here's approximately how it works (though you can vary the lengths of time used). Have your PHP script (the one the client requests) run a (semi-)infinite loop that checks for a new message in the database. If no message is found, use the sleep() function to wait for ten seconds or so before the loop goes through again. Once a message is found, send it out to the client and break out of the loop. The client can then display the message, then start a new request to the "long polling" PHP script, another ten seconds later.

Here is a demo PHP script: $username=$_GET["username"];

<?php
while(1) {
    $messages=mysql_query("SELECT * FROM `msghistory` WHERE `to_id`='$username'");
    if (!mysql_num_rows($messages) === 0) {
        //do whatever message processing and printout you need to do here
        break;//break out of the loop. the script terminates and returns its messages to the client
    }
}
?>

In the near future, we are going to see the implementation of WebSockets, which allow for real-time, push-pull communication between client and server. In many cases, though, this technology is not yet ready for use. Until then, long polling is the way to go.

Ashley Strout
  • 6,107
  • 5
  • 25
  • 45
  • 2
    Don't do this unless your http server is designed to handle lots of simultaneous connections. Apache, for example, is configured by default to only spawn a handful of threads. Meaning after the first few users connect your website will be unreachable. – Kane Wallmann Feb 08 '12 at 02:40
  • I second Kane's note. Apache will be better able to handle tens of thousands of short finite connections better than a few hundred persistent connections. Regardless of which direction you go (long-polling vs ajax) You might want to think about setting up a lighter webserver dedicated to the chat... something like Lighttpd or Nginx which can have larger numbers of max_clients or a larger number of simultaneous requests given the same memory/CPU conditions. – Ben D Feb 08 '12 at 03:25