Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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)?
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:
insert delayed to store them in database.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).
