Stress test tools for chat?
RKR
Anyone have any insights in stress testing tools which can be used to for
Chat applications. Mercury Loadrunner doesn't seem to do it. Also, if
anyone has recommendations on how you would measure the numbers of users a
server can handle running a chat application, I'd appreciate it if you could
send me an e-mail.
Regards,
-Rahul
--------------------------
e-mail: rahul...@intel.com
David Schwartz
RKR wrote:
> Anyone have any insights in stress testing tools which can be used to for
> Chat applications. Mercury Loadrunner doesn't seem to do it. Also, if
> anyone has recommendations on how you would measure the numbers of users a
> server can handle running a chat application, I'd appreciate it if you could
> send me an e-mail.
The only well to tell is to test it in the real world. Network
conditions are the largest factor in determining the amount of load the
server can take.
DS
Ian Westcott
: RKR wrote:
I'd certainly back this up. You can load up 10,000 clones on a server
simulating real activity, but that doesn't mean you can have any idea
whether or not the server will support 10k users.
--
Ian Westcott Rakarra@IRC
rak...@pacbell.net
David Schwartz
Ian Westcott wrote:
> I'd certainly back this up. You can load up 10,000 clones on a server
> simulating real activity, but that doesn't mean you can have any idea
> whether or not the server will support 10k users.
On the other hand, if the server melts handling 10,000 clones, it
almost certainly won't be able to handle 10,000 actual users. And
loading it with clones to profile CPU usage might give you an idea of
some areas of the software that need improvement. So there are reasons
to do clone testing.
Here are some reasons laboratory testing doesn't give you any clue
about real-world chat performance:
1) The connect/disconnect rate is as important as the number of
connections. Laboratory tests tend to grossly underestimate this rate.
2) Real clients execute a more complex mix of commands than you can
usually simulated. (See #8 for more on this)
3) The network paths to real clients tend to drop packets, corrupt
packets, and deliver packets out of order.
4) The slower connections speeds to real clients causes more outbound
data to back up on the server. This causes a cascade performance drop as
the backed up data blows out the CPU caches.
5) Real-world network links have outages that last a few seconds or
more. One outage can affect a large percentage of the user load, causing
the server to suddenly back up large amounts of data.
6) Some percentage of your clients will have broken network stacks or
be behind firewalls or proxies that cause protocol violations. This
causes your operating system to 'slow path' more of its networking
operations.
7) The greater number of distinct destinations will change the CPU
usage of both your operating system and your server code.
8) Real world clients may launch small attacks on your server,
intentionally or accidentally. A good example would be 50 clients
concurrently executing a 'LIST' command. Another example might be two
scripts fighting over a person's channel operator status. It's hard to
simulate this complex mix of behavior.
DS