Help load testing - making many JDBC calls from different IP's

["Kenneth R. Lancaster" <dl...@bellsouth.net>]

Hi everyone,

I have a problem I could really use some help with.   I have been helping
a client test the scalability of an oracle database installation.   The
environment is really client server in that they have an java app
communicating directly to the database via jdbc.  Each client opened around
7 connections to the database.   Since they are wanting to scale to many
1000s of users, the fact that the java clients maintain a heavy weight JDBC
connection to the DB server is not good for scalability. (No... I had
nothing to do with the initial design of this thing.  I am just trying to
get it to scale without rewriting the whole thing :-)

Enter a product from Oracle called Connection Manager that does "IP
Connection Multiplexing".  This product basically changes the architecture a
little bit to make it look like 3 tiers.  It is a server side component that
sits between a java client/applet and the database.  It looks at incoming
connection to the database and maps all connections from a given IP to ONE
active persistent connection to the actual database. Kinda cool.  Because
its sole purpose in life is to maximize use of connections to the database.
This relieves the database server of the massive load incurred by managing
an upper bound of 10,000 mostly idle connections.

The problem that I am having is that I need to test this puppy.  To be more
specific, Connection Manager creates one  persistent connection to the
database for all connections arriving from a given IP address.   The
assumption is that each client has a unique IP so lets say 7 client
connections get mapped/multiplex to one live connection to the database.
In order to test it I need to make a LOT of JDBC call from a LOT of
different IP addresses.   I cant find a java product that will allow me to
bind to different IPs in order to test.  So my question is can JMeter do
this, or do any of you know of a way to do it in Java?

Thanks for any insights you may have.
Ken



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>