Chat application - write to file and then save in database

Question

I have followed this approach that is described here to implement a simple chat application: https://code.tutsplus.com/tutorials/how-to-create-a-simple-web-based-chat-application--net-5931

I'm writing to a file and reading from the file.

I want to implement a feature that saves the chat history when the chat is not active (when no one has written something in a while).

To do that, I would take the file with the chat messages, read It and insert every message as rows in the database. After the insert to the database is finished, I will remove the file.

Next time someone visit the chat, the history is fetched from the database.

When someone starts to write new messages to the chat, I would go with the same approach: Write to a new file, then read from the file.

But I was wondering about the performance here.

As you can see, a ajax-request is made every 2,5sec to the backend that reads the file and return it's content.

My question is: Is this a valid way to go and is it more efficent to read from the database instead of a file on the filesystem every 2,5sec?

Answer 1

The efficiency part of the question can't be answered with the given context since all we know is a client will make a request every 2.5 seconds. At a high level we don't know how many clients there will be concurrently using the application, how big the file can get, what type of database is being used, etc. We also don't know what is important to you. Just disk IO? Client performance? Network? CPU? All of them, but some weighted more than others? So the file vs database would best be done by you measuring performance of each under a predicted load and monitoring what aspects are most important to you.

But the question of 'is this a valid way to go', I would first ask, if you are using a database to store/read the messages, what benefit are you gaining by having a temporary file store messages? Why not directly write new messages to the database?

Without the file, when a client polls the server for new messages they can pass either a timestamp of their last retrieved message, or their last retrieved message id and the database can retrieve messages posted after that date or id. You won't have to return information the client already has. Consider the chat is very active and the file doesn't have a chance to write to the DB and clear. You also won't have to worry about a new client joining, reading the messages from the database, you triggering the file read to database and delete file before the clients 2.5 seconds pass, and now the client is missing those latest messages.

Right now, if chat is very active and the file doesn't 'purge', you would be sending a lot of unnecessary data back to the clients. Whether or not this is going to cause an actual performance hit you would need to determine, but at the least it's unnecessary data which would indicate a larger design issue.