Stress test

in Help Center
We are conducting a stress test of UDP & TCP connections using the ICE library.
On the server side we are going to have one communicator for TCP and one for UDP within the one application.
I am uncertain how to configure the client side to simulate multiple clients trying to connect to the server.
Do i need to run a number of executables simultaneously or can i create multiple client objects within the same application.
I have experimented with creating multiple clients within the one application,pseudo code as follows :
loop 1
create interface proxy for each client
loop 2
execute interface function on every second clients proxy.(we only want half the connections to be active)
Does this result in each client instance getting a different port assigned or is there better way to set this up.
Thanks in advance.
On the server side we are going to have one communicator for TCP and one for UDP within the one application.
I am uncertain how to configure the client side to simulate multiple clients trying to connect to the server.
Do i need to run a number of executables simultaneously or can i create multiple client objects within the same application.
I have experimented with creating multiple clients within the one application,pseudo code as follows :
loop 1
create interface proxy for each client
loop 2
execute interface function on every second clients proxy.(we only want half the connections to be active)
Does this result in each client instance getting a different port assigned or is there better way to set this up.
Thanks in advance.
0
Comments
Thanks for the ideas for the stress test. I was able to get everything up and running.
We have experienced an intermittant problem with the client hanging.
The client hangs on the first checkedCast call that it makes - it goes into endless loop & server is not connected to. The code currently works on my machine but when another developer tries to build it from our cvs - it hangs at the checkedCast point. Both of us are running windows XP.
Here is the code from server & client :
Client :
Ice::CommunicatorPtr ic = Ice::initialize(argc, argv);
Ice::ObjectPrx base = ic->stringToProxy("StressTCP:tcp -p 11111");
StressTCPPrx proxy = StressTCPPrx::checkedCast(base);
Server:
Ice::CommunicatorPtr ic;
SummaryStats::instance().Init();
Ice::StatsPtr statsptr = new IceStats;
try
{
ic = Ice::initialize(argc, argv);
ic->setStats(statsptr);
// Create TCP Adapter
Ice::ObjectAdapterPtr adapter_tcp = ic->createObjectAdapterWithEndpoints("TCPAdapter", "tcp -p 11111");
Ice::ObjectPtr object_tcp = new StressTCPI;
adapter_tcp->add(object_tcp,Ice::stringToIdentity("StressTCP"));
adapter_tcp->activate();
// Create UDP Adapter
Ice::ObjectAdapterPtr adapter_udp = ic->createObjectAdapterWithEndpoints("UDPAdapter", "udp -p 11112");
Ice::ObjectPtr object_udp = new StressUDPI;
adapter_udp->add(object_udp,Ice::stringToIdentity("StressUDP"));
adapter_udp->activate();
ic->waitForShutdown();
}
catch (const Ice::Exception & e)
{
cerr << e << endl;
}
catch (const char * msg)
{
cerr << msg << endl;
}
if (ic)
ic->destroy();
Since it works for you, but not on the other machine, I suspect that the other machine's built environment is broken.
I have been able to reproduce the problem on my work laptop so can provide the call stack :
KERNEL32! 7c57e592()
MSVCRTD! [email protected] + 57 bytes
Ice::ConnectionRefusedException::ice_throw() line 522
IceInternal::ProxyFactory::checkRetryAfterException(const Ice::LocalException & {...}, int & 2) line 118 + 13 bytes
IceProxy::Ice::Object::__handleException(const Ice::LocalException & {...}, int & 2) line 631
IceProxy::Ice::Object::ice_isA(const _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & {...}, ...) line 126
IceProxy::Ice::Object::ice_isA(const _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & {...}) line 105
IceInternal::checkedCastImpl(const IceInternal::ProxyHandle<IceProxy::Ice::Object> & {...}) line 291 + 45 bytes
IceInternal::checkedCastHelper(const IceInternal::ProxyHandle<IceProxy::Ice::Object> & {...}, void * 0x00000000) line 76 + 13 bytes
IceInternal::ProxyHandle<IceProxy::StressTCP>::checkedCast(const IceInternal::ProxyHandle<IceProxy::Ice::Object> & {...}) line 238 + 17 bytes
main(int 1, char * * 0x00516210) line 119 + 13 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 7c581af6()
You should add a catch clause for Ice exceptions, and print them on standard output, like in the demos.
I have a feeling the problem has something to do with the ip address of the server. A couple of questions ...
(i) Is there a way I can find out what IP address the server is listening on.
(ii) What is the format for specifying the host address when the client is connecting.
Yes, run the server with the property Ice.Trace.Network=1.
If the client is constructing a proxy from a string, then the format is
identity:protocol -h host_or_IP -p port etc.
You can use a hostname or an IP address as the argument to the -h option.
If the client is using a proxy that it received from the server, then the proxy contains the endpoints of the server's object adapter used to create the proxy. You must make sure that the object adapter's endpoints are accessible to the client.
Also note that the object adapter does not automatically listen on all available network interfaces. If you specify an endpoint of tcp -h 127.0.0.1 -p 10000, then the object adapter will only listen on the interface for 127.0.0.1, meaning no other hosts will be able to connect to it on that endpoint. If you want the adapter to listen on multiple endpoints, you must specify each one individually.
See the manual for more information.
Take care,
- Mark
I finally tracked it down to not having a stlport preprocessor directive - my project was linking to the ice debug library which in turn is linked to the stlport debug dll. My application was linking against the stlport release dll.
I added _STLP_DEBUG as a preprocessor directive and everything worked.
Thanks for your support on this.
Is it possible to have multiple client connections (& client ports) within the same thread.
We are wanting to simulate multiple (1000 for example) open connections on the server.
At the moment i am opening a new communicator for each connection on the client side which tops out at about 350 because it runs out of threads on the client. Also there is overhead with so many threads open.
I was wanting to have more connections with less threads open.
By the way, I do not believe that the result will be meaningful. There is no problem for a Wish server to handle a large number of connections. Also note that Wish automatically closes connections that have been idle for a certain timeout period. Such connections are then transparently reestablished when a new request is sent. (That's called Active Connection Management.)
I still don't see the point of this test. Do you want to test if a server can accept a few thousand connections, of which most are then idle? It sure can! Do you want to test if a server can handle heavy simultaneous traffic on all these connections? Only if you have a very high end computer, that can handle all the processing! The limits are not set by Ice, but by the time it takes to process each request in your server code.