Take the 2-minute tour ×

There are 1 on 1 live chat. Two solutions:

1) I store every message into database and with jQuery's help I check if there is a new message in database every second. Of course I use cache either. If there is, we give that message.

2) I store every message in one html file and every second through jQuery that file is shown over and over again.

What is better? Or there is third option? And in general, what is better, mysql or file for this kinda project?

Thank you very much.

P.S. The most important question is: what is more efficient and what way will eat less resources!

Edit: And is it, nowadays, very bad for many chats (let's say 2,500 chats, that means 5,000 users) to use long polling and check when file was edited every second through javascript? I use very similiar methods like this chat: http://css-tricks.com/jquery-php-chat/ Will it kill my hosting?

share|improve this question
How volatile are live chats? How long is a chat session? Will live-chat parameters ever change? –  Khez Apr 13 '11 at 21:20
Do you need the chat to be persistent? Then a database is best. If not, Random Access Memory is fine. How about Session variables, memcached, MEMORY TABLEs? –  Konerak Apr 13 '11 at 21:21
It has to be persistent until somebody finishes the chat. I want to make it as effective as possible to use as less resourses as possible. –  good_evening Apr 13 '11 at 21:23
add comment

13 Answers

up vote 8 down vote accepted

Everyone has given a wide range of opinions but I don't think anyone has really hit the nail on the head.

When it comes down to storing data, the amount of data, the rate it is to be accessed, and several other factors all determine what's the best storage platform.

Some people have suggested using memcached. Now although this is a valid answer (you can use it), I don't think that this is a good idea, solely based on the fact that memcached stores data within your server's memory.

Your memory is not for data storage, it's for use of the actual applications, operating system, shared libraries, etc.

Storing data within the memory can cause a lot of issues with other applications currently running. If you store too much data in your RAM your applications would not be able to complete operations assigned to them.

Although this is faster then a disk based storage platform such as MySQL, it's not as reliable.

I would personally use MySQL as your storage engine server-side. This would reduce the amount of problems you would come across and also makes the data very manageable.

To speed up the responses to your clients I would look at running node on your server.

This is because it's event driven and non-blocking.

What does that mean?

Well, when Client A requests some data that is stored on the hard drive, traditionally PHP might say to the C++, fetch me this chunk of data stored on this sector of the hard drive. C++ would say 'ok no problem', and while it goes of to get the information PHP would sit and wait for the data to be read and returned before it continues it's operations, blocking all other client's in the meantime.

With node, it's slightly different. Node will say to the kernel, 'fetch me this chunk of information and when your done, give me call', and then it continues to take requests from other clients that may not need disk access.

So suddenly because we have assigned a callback to the kernel, we do not have to wait :), happy days.

Take a look at this image: Node Event Loop

This really could be the answer your looking for, please see the following for a more descriptive and detailed information regarding how node could be the right choice for you:

share|improve this answer
Ah, the power of the Asynchronous Programming Model (APM) –  Prisoner ZERO Apr 19 '11 at 17:53
could I handle 5k-10k online users if I use this type of chat: css-tricks.com/jquery-php-chat , in your opinion? And what hosting's parametres do I need to have to handle it. –  good_evening Apr 22 '11 at 20:58
Easily with a decent server, it powers Plurk which has 110K+ users online at once, amix.dk/blog/post/19490 - You would need a dedicated server where you have shell access, obviusly you need a very large connection and large amount of cores and ram, you would need to learn about splitting a node server across several cores > developer.yahoo.com/blogs/ydn/posts/2010/07/… –  RobertPitt Apr 22 '11 at 21:51
add comment

A fourth option, probably not what you want if you already have php code you want to use, but maybe the most efficient is to use a javascript based server instead of php.

Node.js is easily capable of being a chat server and can store all the recent messages as a javascipt variable.

You can use long polling or other comet techniques so that you so not have to wait a second for messages to update.

Also, the event based architecture of a javascript server means that there is no overhead for idling around waiting for messages.

share|improve this answer
I think the question relates more to the storage of the data, and the speed the data can be accessed at, no so much about node's event driven framework capabilities, although it's good that you mentioned it¬ –  RobertPitt Apr 15 '11 at 23:29
I think node.js solves the storage problem because it is event driven, and is able to store the required data as javascript variables in memory. I think the answer may not be suitable because it requires a re-write of any server side code. –  Billy Moon Apr 15 '11 at 23:32
storing the data in the memory should not be an option, why would you want to store that sort of data within the memory ? that's why database were invented to have a storage platform that's reliable within large environment's ? –  RobertPitt Apr 15 '11 at 23:38
I assume that the chat application is only going to store the last x number of messages in a given chat room, and then distribute them very frequently to all members in the room, so it seems like an unnecessary processing and slow-disk-access overhead to continually read and write these to a database. As I understand it, the information stored only needs to be kept for long enough to be delivered to all recipients (logged in to chatroom) then can be removed. Therefore, not bloating in memory. Do you disagree with this idea? Please elaborate on how a database would be used in this circumstance. –  Billy Moon Apr 15 '11 at 23:53
add comment

It depends on number of chats in the same time. If it's for support and you expect average load to be 1 to 5 chat sessions at a time then you don't to worry too much. Just make sure that when there is no activity for some time stop refreshing and show a message for user to click to resume chat session.

If the visitors will chat with each other and you expect big number of sessions - 10-50 at the same time you can still use PHP + database. Just make sure you don't make redundant queries and your queries are cached correctly. To reduce load you can also deny chat script from being logged in web server:

SetEnvIf Request_URI "^/chat.php$" dontlog


you can have delay schema. For example if you query 2 times with delay 1 second and you get no data you can increase delay to 2 seconds. if you reach 10 queries with no response - increase delay to 5 seconds. After 10 minute you can pause the conversation, requiring users to click on a button to resume the chat. That'll, combined with advices above will guarantee low enough load to have many concurrent chats


I suggest you to find some flash or java solution and buy it. With 5000-10000 users you have to be genius to make it work on VPS, especially if RAM is not much. Not that it's not possible but you can rent cheaper VPS and with the rest of the money buy some solution in java or flash (don't know if flush supports 2 way connection, I'm not a flash expert).

Note about number of users: if you have 10 000 users my guess is that you'll have not more than 100 chats at the same time. Go and look dating sites - they have not more than 10% of the users online and maybe most of them are doing something else and not chatting

share|improve this answer
how can I delay it? Then newest messages won't come up after they are posted. –  good_evening Apr 21 '11 at 10:13
Yes, but if someone have waited 3-4 seconds for response one second more won't make a difference. if it happens that you wait 10 seconds for reply then it doesn't matter if it's 13 seconds. And if you wait 60 seconds, then 65 seconds will seam exactly the same time - you won't be able to tell the difference. Well the one that posted the message might have to wait 5 seconds more to get response, but since he was not there for a whole minute then he probably can't expect fast answer. Well, refresh in more than 5 second intervals. –  NickSoft Apr 21 '11 at 13:41
I see your point now, nice advice. –  good_evening Apr 21 '11 at 16:08
So, if I use idea for a chat like here css-tricks.com/jquery-php-chat and I will add your advice, do you think that I could handle ~5,000-10,000 users at the same time on VPS? –  good_evening Apr 21 '11 at 16:17
more than 5000 users online at the same time is really big expectation. If you use memcache you could handle the number (depends on dedicated cpu speed). I don't know how much ram will it require. But if you use memcache handler for session and you cache everything into memcache then I don't see a problem. if you measure a script that checks for new message using memcache it'll run few miliseconds. That means 100s of queries per second. If I were you I would rent the vps and do a stress test. It's not hard to emulate it. But that's just answer of your question. I would do it in java or flash. –  NickSoft Apr 21 '11 at 20:25
add comment

3rd option. use MEMCACHE. infinitely faster read/writes. perfect for your application.

share|improve this answer
are you sure memcache is a good way to create chat? –  good_evening Apr 14 '11 at 13:54
I dis-agree, Memcache places data in the ram to use across sessions, if he had 1K people chatting, the memory would fill up pretty dam quickly –  RobertPitt Apr 15 '11 at 23:28
memcache will roll off the oldest data, we use it to store literally millions of datasets –  FatherStorm Apr 20 '11 at 18:18
add comment

Store the chat messages in the database but use Memcached as a caching layer for the database reads. So the most popular reads (e.g. the last 20 messages in the chat room) will always be served straight out of memory.

This gives you the benefit for speed for the most frequent operations and persistant storage for all of the messages.

share|improve this answer
add comment

Just to throw in another option... flat files could provide a less resource-hungry alternative.

Every chat is assigned a unique ID and a flat file stored for it. Every chat adds a line to this file. Each client machine then uses jquery to check ONLY the modified date of the file, to see if the chat has been updated.

While I would never normally recommend flat files over a database, I have a sneaky feeling that checking the modified date on a flat file would scale up better than the MySQL alternative.

I was intrigued so I did some tests and here are the results:

  1. With an existing db connection, the number of "SELECT field FROM table LIMIT 0,1" that could be run in 1 second: ~ 4,000

  2. Opening and closing a db connection, but running the same query: ~ 1,800

  3. Checking the modified date on various different files: ~225,000

So to check if a conversation has been updated, storing the conversations in flat files and checking for the last modified date would easily be faster than doing anything with a database.

share|improve this answer
add comment

In general, http connections are not very useful when it comes to pushing data to the client. Doing polls at every x seconds tend to be a resource hog on any server, given you have significant traffic.

You should try XMPP combined with BOSH. Luckily, most of the heavy work is already done for you. You can implement a pure jquery (or other js framework) based solution very quickly. Read this tutorial, it will help you a lot - not only solving your specific problem but, giving you a broader view on how to implement push technologies over the good ole' http.

share|improve this answer
add comment

Unless, its a small-audience script - Between Database vs File-System, its better to use Database(.)

P.S:- Flash also makes a great platform for chat servers, you might wanna look into that aswell.

share|improve this answer
add comment

If you define a conversation as only two people, then a request every second is going to look like one read request per second per user, and one write request every time somebody writes something (say every 10 seconds). So every 10 seconds you will have about 2.2 requests per second, per conversation.

For 50 conversations, that's 100 users and 220 requests per second. That's a lot of load on a server for such a small number of conversations. Writing the conversation to JSON or XML, would probably provide a more scalable solution.

This article discusses the architecture of Meebo - long-polling, comet.

As an afterthought, have you considered installing an IM server like Jabber rather than starting from scratch?

share|improve this answer
Is 220 request per second for javascript a lot? –  good_evening Apr 20 '11 at 13:50
@hey - Sorry, was a bit vague, I was referring to the MySQL side. And it's not so much the absolute number of requests, as the comparison between the number of users and the amount of work the server is having to do. –  Blowski Apr 20 '11 at 23:44
add comment

you could always get the right tool for the job ... an XMPP compliant bit of software. for as poor as the documentation is, ejabber is pretty alright. because it follows closely the XMPP standard: http://code.google.com/p/ijab/ you can use any XMPP client. You can store all of it in an RDBMS if you like and provide similar functionalities that are offered in gmail / google talk.


share|improve this answer
add comment

A really fast alternative could be a NoSQL database like MongoDB:

  1. MongoDB homepage
  2. Some benchmarks
  3. MongoDB's extension homepage on php.net
share|improve this answer
add comment

I don't use it but you maybe can try Photon , a very high speed framework based on Mongrel. On the author blog (in french) you have a example , 30 lines of code for a real time chat server, with video demonstration.

share|improve this answer
add comment

I think storing the data on the database is better. Please refer the following link Script Tutorials Chat

share|improve this answer
add comment

Your Answer


