Please see my comments inline.

Regards,

Ali Sadik Kumlali

--- "Ramanathan, Subramanyam" <[EMAIL PROTECTED]> wrote:

> Hi, 
> 
> These are the test results that I got using jmeter (I will also
> update the issue).
> 
> 
>                 Axis2                Axis1
> 
> 10 threads -  avg 1493.27           avg 664.77
> 20 threads -  avg 1436.67           avg 649.97
> 30 threads -  avg 1334.5            avg 639.93
> 40 threads -  avg 1227.9            avg 639.57
> 
> Percentage drop for axis2 - 17.8
> Percentage drop for axis1 - 3.7
> 
> The throughput figures are, however, higher than what I got using my
> client. 
> I checked up the mailing list archives of jmeter, and some threads
> there seemed to indicate that they too, use 
> #Responses/Total Test Time as the measure of throughput.. I wonder
> what is the matter with my client, then, as I have used the same
> measure, too. The difference probably is in the way jmeter calculates
> the total test time, I am not sure, I hope someone could give me a
> hint regarding this?
> 
> I have implemented my test service with the XmlBeans data binding.
> Our specific wsdl involves complex extensions and restrictions, so
> adb cannot be used, and jaxme wasnt working, either (code generation
> failed with a CodeGenerationException saying wildcards aren't
> supported). So I had to stick to XmlBeans.
> 
> Could someone please tell me, what is the performance of XmlBeans is
> as against adb and jaxme ?
https://bindmark.dev.java.net/

> Thanks and regards,
> Subramanyam
> 
> 
> -----Original Message-----
> From: Ramanathan, Subramanyam [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 30, 2006 3:46 PM
> To: [email protected]; [EMAIL PROTECTED]
> Subject: RE: [Axis2] Multithreaded client, performance degradation.
> 
> 
> Hi,
> 
> I have just created an issue on jira with key AXIS2-780, and I have
> attached the code.
> 
> I did not know about jmeter earlier, so I decided to try testing it
> using jmeter also, using an aggregate reporter.
> However, I don't find a big variance in the throughput figures that
> it gets. These are the values, I repeated the run three times for
> each number of threads.
> 
> loop count 1000
> 10 threads - 241, 243, 259
> 20 threads - 237, 229, 233
> 30 threads - 233, 230, 227
> 40 threads - 227, 231, 226
> 
> I don't know how exactly jmeter runs the test and calculates the
> throughput, and I don't know if the overhead of the framework is
> levelling the figures out, because I got much larger values for
> throughput, particularly for smaller number of threads.
> 
> My client spawns n number of threads, and each of them send r
> requests. 
> My calculation was based on startTime taken before spawning threads,
> endTime taken after all the threads are done, 
> and reqPerSec  = ( n * r )*1000/(time diff in millisec). Is there a
> problem with this ?
> 
> I also did a test by spawning only 10 threads from a client at a
> time, but running the client on multiple machines at once, 
> and that gave me approximately the same figures, too.
> Also I have used exactly the same client to post to axis1.
> 
> 
> Thanks and Regards,
> Subramanyam
> 
> 
> -----Original Message-----
> From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 29, 2006 10:53 PM
> To: [email protected]
> Subject: Re: [Axis2] Multithreaded client, performance degradation.
> 
> 
> Subramanyam,
> 
> I am just now running a jmeter based multithreaded test with
> 1,5,50,100,200 threads and i *definitely* don't see what u are
> seeing.
> Could u please create a JIRA issue and upload both your service and
> client code?
> 
> -- dims
> 
> On 5/29/06, Ramanathan, Subramanyam <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've been running a few performance tests on Axis2 to compare it
> with Axis1.
> > I've found that when I post requests using a multithreaded http
> client [ that spawns multiple threads each sending a certain number
> of requests ] , the performance of Axis2 seems to degrade, whereas
> that of Axis1 seems to be relatively stable when tested using the
> same client.
> >
> > Here are the figures I have got. Each thread sends 1000 requests.
> > I have measured throughput by measuring the time taken for all the
> threads to finish and then calculating requests per sec.
> >
> >
> >                         Axis2(req/sec)          Axis1(req/sec)
> >                         --------------          -----------
> >     10 threads  - 1105.530784                   545.9761944
> >     20 threads  - 635.3480599               556.6025772
> >     30 threads  - 411.2374179             550.5108726
> >     40 threads  - 215.8165598             570.8683581
> >
> >
> > Apparently, as the number of threads increases, the performance
> drops in Axis2 whereas it remains reasonably stable in Axis1.
> > Can someone tell me the reason for this, and is there any way the
> performance with multiple threads in Axis2 can be made better /
> stabilized ?
> >
> > My Setup:
> > ---------
> > Red Hat Enterprise Linux ES release 4
> > Axis2 version 1.0
> > Tomcat 5.5.17
> > jdk 1.5.0_04
> >
> >
> > Regards,
> > Subramanyam
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> -- 
> Davanum Srinivas : http://wso2.com/blogs/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to