How many members will an AJAX chat be able to handle on a dedicated server before it overloads and becomes slow?

The details of the dedicated server (at the time the site starts) are as follows:

OS: Linux CentOS

CPU: Intel® Pentium 4 - 3.0 GHz

RAM: 2 GB

Storage: 2 x 120 GB hard drives

Bandwidth开发者_高级运维: 500 GB per month

The AJAX chat is customly coded. It runs by sending and receiving Javascript commands to and from the database, and then evaluating them.

The chat refresh rate will probably be somewhere around 250ms, although the answers here may change the decision.

If you want to implement browser-based chat application that's going to work on a relatively cheap server and be able to serve lots of users (say, 500 at a time) without crashing - your approach isn't effective.

Reasons: using DB to send JS to the clients who evaluate the code isn't really safe. It's also expensive. It also means that per every line of chat, you need to invoke the DB at least once. That implies A LOT of I/O for the RDBMS.

If I were you, I'd check out Node.js.

Node.js allows you to write chat servers in JavaScript. The JS itself is not executed by the browser but by server. It is extremely I/O efficient. It is also simple enough to allow a non-expert programmer to create proper chat apps.

Using php for chat server isn't a good idea. Polling can give too much unnecessary load to server and doesn't scale well. In my opinion you should rethink whole architecture.

1. Polling is bad for chat - use Comet (long polling) instead
2. With comet you will need fast HTTP server which can handle thousands of concurrent connections - use NGINX
3. PHP isn't good solution for chat app - process-like non-blocking solution is much better - look at Tornado and their chat example
4. From now on you must decide whether you need to scale - if not you can write single-thread server on top of tornado and store all data in memory - of course you will need to delete old unneeded data. If you need to scale choose fast scalable datastore like MongoDB - you'll have to poll database - but it will be single query for ALL clients connected to single tornado instance - not for every client

Facebook used (or still uses) this kind of architecture (using MySQL backend) for their needs