Scalability of ajax chat
ive got a site that uses ajax chat about to launch. we've got a pretty good dedicated server. my question is this:
how many people using this site, chatting at a time (via ajax) would you estimate before the server just got bogged down? I'm trying to figure out how much time we have to move the system over to a more scalable push technology.
1,000 users? 10,000? 100,000?
Any insight is appreciated. Thanks
the311guy posted this at 11:02 — 24th August 2009.
They have: 9 posts
Joined: Mar 2005
Anyone know at all??
davecoventry posted this at 12:59 — 24th August 2009.
He has: 112 posts
Joined: Jun 2009
I would guess it would depend on the frequency of calls to your database.
If you set it to poll the database every second, you are going to have problems a lot earlier than if you poll it every 10 seconds.
I know this is obvious, sorry.
Which ajax chat client are you using?
JeevesBond posted this at 13:16 — 26th August 2009.
He has: 3,956 posts
Joined: Jun 2002
This depends so much on the application and how well it's written!
You should create some automated chat scripts to simulate conversation, then see how much you can load the server before it gets into trouble.
Sorry if that wasn't the answer you were looking for, but if I were to try giving an arbitrary number I would just be pulling it out of my arse.
a Padded Cell our articles site!
davecoventry posted this at 15:41 — 26th August 2009.
He has: 112 posts
Joined: Jun 2009
JB, with reference to your comment on how well the application is written, if you were writing an ajax client, what would you be on the lookout for in terms of minimising server load?
I'm thinking that the timing mechanism should be in the javascript so that the browser and the client machine can deal with it, but obviously the access to the database has to be handled on the server.
Shaggy posted this at 13:04 — 2nd September 2009.
They have: 121 posts
Joined: Dec 2008
Late to the party again...
Benchmark it. Send 'ab' or 'seige' (or other flavours of the day) after each of your publicly accessible components with increasing numbers of simultanious connections and requests, and see how the io, cpu, etc. hold up.
It's the only way to get an even half-accurate estimate of what you'll be looking at before the faceless hoards come a-knockin'.
Cheers,
Shaggy.
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.