Most of simple "group chat" systems are based on local file storage logs (e.g. log.txt ).

I'm developing a simple group chat (under 20 users simultaneity ) with jQuery/AJAX.

So basically, client-side code loads log from server every second. It needs to be fast.

In database system (PHP/MySQL) that would mean MySQL query every second. Is that overload for server (shared hosting)?

  • Could you expand on whether or not you need persistent data, and whether access to the persistent data needs to be fast? If you only need to persist the data for auditing purposes, keeping the chat data in RAM looks like a better idea to me; there are lots of technologies for this but memcache comes to mind. Apr 8, 2012 at 8:05
  • 3
    It would be interesting to see what your proposed schema would look like.
    – NoChance
    Apr 8, 2012 at 10:22
  • There are numerous IRC servers and AJAX client implementations that work well. Why re-invent the wheel?
    – Blrfl
    Apr 8, 2012 at 12:40

5 Answers 5


I've done this before, in the days before AJAX frameworks were widely used. Using a database was fine. The trick is to make sure that each client knows the ID of the latest message that it's seen. Each time the client asks for new messages, it should submit this ID. Then when you query the database, retrieve only those messages whose ID exceeds the one provided by the client. This will be a very fast query, that should only return a small handful of rows at the most.


Caching is your answer.

If your shared hosting has enough resources (your application shouldn't demand much) and has some kind of cache system installed, it should be a breeze with caching.

A few ways to do it:

  • store the messages in the memory directly and retrieve from there,
  • store the messages in the memory and use insert delayed to store them in database.
  • store the messages to database, and query the database on intervals and store them in memory.

Apc and memcache are some of the caching solutions out there. Or you can use mysql caching also.


As with anything on shared hosting, it depends a little bit on what else is running on the same server, trying to use the same resources. Provided your host has a sufficient fair-usage policy in place, I think a database query every second for 20 people (the max you stated) would be fine.

If you really need this to be fast, you should really invest in some better hosting though - it is dirt cheap nowadays.


IMO a better way would be for the client to request updates and send it the new lines

you can do this by keeping the last 50 lines in a queue (each timestamped)

  • when a client joins you can send it the entire queue

  • when the client requests an update find the section that was added since the last line the client requested (the timestamp of which the client provided in the request) and send those

  • when the client posts a line you added it to the queue and purge the oldest line

no calls to DB and no disk access => fast

if you need logs when a line is added add it to a buffer that you flush periodically to whatever storage system you want to use


Relational databases are supposed to do exactly that kind of work, log files are not. We can of course argue that there are better/faster solutions but this was not a question at hand so I will skip this.

If you know how to normalize data & use indexes there should be no problem at all but I would suggest archiving older chats into separate set of tables (eg every night move all chats older then 2 days ) so indexes and live data set would be as small as possible and even possibly data set could be kept in memory (MySQL works blazing fast when it can keep all needed data in memory).

On the other hand having 20 requests per second could be a problem on your shared hosting since those kinds of hostings are not meant for that much traffic( only polling data for 1 chatroom with 20 users would generate 1.7 million requests per day). That number of requests can create problems independently of what is your data source (mysql,log file, memcached,mongo).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.