Pavel,
Thanks again. I am adding your new files to CVS, although I have made
one change. When I ran the test on my uniprocessor machine, I fell
straight through this code on the first loop:
/// Waiting all requests to finish
while (numberRequests > 0) {
Thread.currentThread().sleep(100);
}
In other words, none of the new threads had reached the point where they
incremented numberRequests before this code was reached. I have worked
around this race condition by waiting for the threads to finish:
Vector threads = new Vector(numThreads);
for (int i=0; i<numThreads; i++) {
Thread t = new Thread( new ComplexRequest(), "Run: " + i);
t.start();
threads.addElement(t);
}
/// Wait for all requests to finish
for (int i=0; i<numThreads; i++) {
try {
((Thread) threads.elementAt(i)).join();
} catch (InterruptedException ie) {
}
}
This works for me, and I think it should work better in general.
Scott Nichol
----- Original Message -----
From: "Pavel Ausianik" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 04, 2002 12:39 PM
Subject: RE: [PATCH] Simple performance tests
> Seems like cmd was blocked
> Now all files zipped
>
>
> > -----Original Message-----
> > From: Pavel Ausianik [mailto:Pavel_Ausianik@;epam.com]
> > Sent: Monday, November 04, 2002 7:30 PM
> > To: 'Scott Nichol'; '[EMAIL PROTECTED]'
> > Subject: [PATCH] Simple performance tests
> >
> >
> > Hello,
> >
> > In discussion of what performance gains we got, I created a
> > very simple
> > performance test, basing on existing addressbook sample
> > (files attached
> > should be added to java\samples\addressbook\ dir, sorry not
> > sure how correct
> > patch should be created for new files).
> >
> > The test allow to run getAddress / putAddress requests in
> > cycle from several
> > concurrent threads.
> > I have tested it within following environment:
> >
> > 2XPIII -600, 1G of RAM, W2K
> > Sun JRE 1.3.1
> > Tomcat 4.0.3
> > Xerces 2.x
> >
> > soap libs 2.2, 2.3.1, current
> >
> > The number of threads was set up to 8 (with more threads I had a
> > socketException). Each test included 4000 calls
> >
> > Before each test server & client SOAP lib was replaced with
> > corresponding
> > version & server restarted
> >
> > The test was performed once in each config, sorry had no time for
more
> > accurate testing, maybe someone will complete it.
> >
> > The results I got following:
> >
> > SOAP ver , Time to run
> > 2.2 107.091
> > 2.3.1 98.841
> > CUR 82.451
> >
> > Best regards,
> > Pavel
> >
> > > -----Original Message-----
> > > From: Scott Nichol [mailto:snicholnews@;scottnichol.com]
> > > Sent: Wednesday, October 30, 2002 6:17 PM
> > > To: Pavel Ausianik
> > > Subject: Re: [PATCH] Improve Key mapping
> > >
> > >
> > > > It would be interesting if some performance measure test for
whole
> > > SOAP env
> > > > (server / client ) could be done in comparison current lib with
> > > 2.3.1...
> > >
> > > I agree. I have a list of things I would like to do with
> > > SOAP, such as
> > > code improvements, new features, more interop samples, but I
> > > get time to
> > > work on them in small spurts, so I know that many things on the
list
> > > will never get done (by me, at least). I am not sure I will
> > > get around
> > > to performance measurements any time soon, but I would love
> > to compare
> > > 2.2, 2.3.1 and the current, as well as a quick comparison of
tomcat,
> > > jetty and resin as containers.
> > >
> > > Scott Nichol
> > >
> > >
> >
> >
>
>
------------------------------------------------------------------------
--------
> --
> To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
--
To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
