1

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?

  • 3
    Possible duplicate of Is micro-optimisation important when coding? – gnat May 17 '18 at 10:47
  • @gnat: So it's micro-optimisation when It comes to databasesystems vs filesystem in this case? – Bryan May 17 '18 at 10:52
  • @Bryan I guess it could be. Are you noticing performance issues with the file-based approach? – neilsimp1 May 17 '18 at 12:10
  • 1
    This is not micro-optimisation, at all. OP is absolutely right to question this. If an approach sounds inherently, and more importantly unnecessarily, taxing it should be reconsidered. It's a good question, in my opinion. There's more to development than just the 'here and now', especially if you want your system to scale. Not that it's even all about scaling - it's just about making the most sensible choices. – JᴀʏMᴇᴇ May 17 '18 at 14:30
5

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.

  • The thing I really wonder Is if it's more efficent/scalable to poll the database (Sql server) every 2,5sec instead of poll a file every 2,5sec? Let's say it's 1000 users using the chat. I have looked at socket.io and all other stuff to use for chat applications, but using jquery and c# as backend is very simple. – Bryan May 21 '18 at 6:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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