[ale] Java Applet Load Testing

[Greg Freemyer]

2008/2/19 Daniel Kahn Gillmor <dkg at fifthhorseman.net>:
> >> Now we want to truly simulate the real environment complete with a
> >> few thousand simulated client machines sending in a very low volume
> >> of transactions.
> >>
> >> I'm thinking of utilizing a large VMware like server, etc. with
> >> hundreds or thousands of nearly identical virtual machines.  The
> >> disk image could be common, and most of RAM shared, but each one
> >> would need to have its own IP, but the rest of the RAM / disk could
> >> be shared.
>
> Why use Virtualization at all?  If you're in your own lab, set up your
> client test system with one copy of the applet, and attach a thousand
> IP addresses to the single NIC.  For example, if you're using a local
> network with IP addresses in the 10.13.x.x/16 range on eth0, do (this
> uses /bin/ip from the iproute package):
>
>  for byteA in $(seq 1 10); do
>   for byteB in $(seq 100 200); do
>    ip addr add 10.13.$byteA.$byteB/16 dev eth0
>   done
>  done
>
> Then launch a thousand applet clients, each bound to a different
> outbound IP address (your applet will need to allow you to populate
> whatever is the java equivalent to sockaddr_in.sin_addr during the
> java equivalent/wrapper to the socket() syscall).
>
> If your hardware can handle running a thousand clients concurrently,
> there's no reason to ask it to handle the additional overhead of a
> thousand VMs at the same time, right?
>
Good idea.  Had not thought about that.  I've done IP aliasing, but
never with a large volume of IPs is there a limit to the number?
10,000 would definately handle everything I can envision.

Early stages of conceptualization as you can see.

>          --dkg
>
> PS Without knowing the specifics of your particular scenario, limiting
>    to one client connection per IP address is probably going to cause
>    trouble for your clients in the near future (if it hasn't already),
>    given the widespread use of NATs and proxies, both of which lump
>    multiple agents (and therefore multiple humans) behind a single IP
>    address.

Now that you mention it, we may have already migrated to a
registration / SN process where each client is given a unit number and
that number is used to ensure no multiple logins.  Will need to look
into that.

Thanks for the sanity check.

Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com