I have a web-based chat script that is similar to IRC. I am trying to increase its efficiency. Right now it uses AJAX to query a database every 250ms to see if there has been any chatting and if there has been it updates that clients window. The problem is that the more clients the more often the server is hit. The server is also queried every time a user speaks. This ends up being resource heavy.

My plan was to use XML to increase efficiency. Tell me what you think. Instead of using a database when a user speaks AJAX just updates the XML document and changes the timestamp to the time of update. Then every 250ms the users client checks the XML document and if the timestamp on the document doesnt match the timestamp they have the user reloads the XML. I am thinking that this should put more of the strain on the user and take it off the server allowing the server to handle a higher number of users.

Anyways tell me if you think that makes sense or if you can think of an even more efficient. Thanks!

Try using a cache around your data layer.
Updates can hit the cache, a background thread can keep it in sync with the database, and queries will bounce off the cache.

Updating a file will get expensive as the file grows

I have never done any work with caches before. Is it very difficult? Can you maybe point me in the right direction as far as good tutorials on the subject.

My favorites are:
Ehcache and OScache
Ehcache is used by hibernate by default.

but, I do most of my dev with java. There are caching solutions for most languages if you use something else.

For example, with hibernate. You ask hibernate for an object, it first checks the cache to see if it has it. If not, it queries the database and stores the object in the cache before returning to you. You can make lots of changes to the object (you just have a ref to the object in the cache). Other requests can ask for the object and get it out of the cache. Hibernate has a background process that syncs the objects in the cache with the database.

So, you could potentially have a 100 changes to the object and only one SQL UPDATE get executed (with the latest version). It's one of the reasons why working with a library like hibernate can have such high performance.

Of course, there options to explicitly flush the cache (sync cache with the database) when working in a transaction dependent environment.

Hmmm I guess I am not fully grasping the concept of a cache. If I am caching data in the user's browser how does that help me with my problem?

Because wont the browser still need to request updates just as often. I guess I can just limit the amount of information that is transfered at a time. Is that what you are thinking?

Sorry, I wan not referring to caching on the browser. Browser caching would break your application

I'm talking about caching data between the database and your application code. This keeps the application from hammering the database so hard.

Nice that makes alot more sense, I will give that a try and see how it works out.