[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] Java Applet Load Testing

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 Freemyer
Litigation Triage Solutions Specialist
First 99 Days Litigation White Paper -

The Norcross Group
The Intersection of Evidence & Technology