Hi Srinath,

I wasn't thinking about doing multiple servers now itself. That would be
impractical. We can just start by increasing the number of clients. Just
using a thread pool and increasing the pool size would do...

On Thu, Feb 9, 2012 at 2:32 PM, Srinath Perera <[email protected]> wrote:

> Hi Tharindu,
>
> Agreed .. lets plan to find some HW and do this when we can (will need
> at least 5 servers) .. I just want us not to be blocked on this.
>
> --Srinath
>
> On Thu, Feb 9, 2012 at 2:01 PM, Tharindu Mathew <[email protected]> wrote:
> > Not testing for load at start lead to problems earlier.
> >
> > Testing for 20 clients and 10 M messages is not the same for testing for
> 500
> > clients and 10 M messages. At this scale only, connection pooling,
> caching
> > and all of this matters. This is of course, many clients to one server, a
> > basic test that can be done easily.
> >
> > Anyway, we can post pone the testing to when we integrate BAM or CEP, but
> > please be aware of the implications. This was a situation where earlier
> BAM
> > was not scaling at all.
> >
> >
> > On Thu, Feb 9, 2012 at 1:43 PM, Amila Suriarachchi <[email protected]>
> wrote:
> >>
> >>
> >>
> >> On Thu, Feb 9, 2012 at 12:36 PM, Srinath Perera <[email protected]>
> wrote:
> >>>
> >>> Hi Suho,
> >>>
> >>> IMHO this covers about 90% of our usecases .. I think we should move on
> >>
> >>
> >> we do not required to do an performance study. Since anyway we don't
> have
> >> proper CEP or BAM service to consume events.
> >>
> >> But need to test for once client many server scenario to test for
> >> stability.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>>
> >>> I do not mind doing a larger perf study later .. ..
> >>>
> >>> but getting the server finished from siddhi side and releasing it, CEP
> >>> perrf numbers,  and integrating this with BAM are more urget IMHO
> >>>
> >>> --Srinath
> >>>
> >>> On Thu, Feb 9, 2012 at 12:29 PM, Suhothayan Sriskandarajah
> >>> <[email protected]> wrote:
> >>> >
> >>> >
> >>> > On Thu, Feb 9, 2012 at 12:00 PM, Amila Suriarachchi <[email protected]>
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Thu, Feb 9, 2012 at 11:47 AM, Tharindu Mathew <[email protected]
> >
> >>> >> wrote:
> >>> >>>
> >>> >>> Suho,
> >>> >>>
> >>> >>> This does not measure the ability to handle load. Basically, what
> we
> >>> >>> did
> >>> >>> for load testing earlier was send around 2M messages, with
> >>> >>> concurrency as
> >>> >>> high increasing from 100 - 1500 clients.
> >>> >>
> >>> >>
> >>> >> How many back end servers and client programs used for that?
> >>> >>
> >>> >>>
> >>> >>>
> >>> >>> Your test is a measure of being able to consistently handle a
> stream
> >>> >>> of
> >>> >>> messages, which IMO, maybe important but is less interesting when
> >>> >>> handling
> >>> >>> load.
> >>> >>
> >>> >>
> >>> >> This test has measured the one client one server. yes it can be
> >>> >> improved
> >>> >> to one client to many servers and many clients to many servers.
> >>> >>
> >>> >
> >>> > This test also covers sending messages from many clients (2,5,10 &
> 20)
> >>> > to
> >>> > one server.
> >>> > Yes it could be improved to many clients to many server.
> >>> > If there are any specific requirements please suggest me a scenario,
> >>> > then I
> >>> > can do the testing and present the findings.
> >>> >
> >>> > Thanks
> >>> > Suho
> >>> >
> >>> >> But this test gives the through put this can handle one client to
> >>> >> server.
> >>> >> For one client scenario whether you add messages with one thread or
> >>> >> many
> >>> >> threads does not effect the performance if there are enough messages
> >>> >> to
> >>> >> send.
> >>> >>
> >>> >> thanks,
> >>> >> Amila.
> >>> >>
> >>> >>>
> >>> >>> To truly test the ability to handle loads we need to do a
> distributed
> >>> >>> load test with an extremely high number of clients and see the
> >>> >>> breaking
> >>> >>> point. Earlier, we could not find such a point with a single
> machine.
> >>> >>>
> >>> >>>
> >>> >>> On Thu, Feb 9, 2012 at 11:31 AM, Suhothayan Sriskandarajah
> >>> >>> <[email protected]> wrote:
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On Thu, Feb 9, 2012 at 11:24 AM, Amila Suriarachchi <
> [email protected]>
> >>> >>>> wrote:
> >>> >>>>>
> >>> >>>>> through put should not depend on the number of messages send. You
> >>> >>>>> need
> >>> >>>>> to send sufficient number of messages after server warmed up.
> >>> >>>>>
> >>> >>>>> Can you please first send around 2M messages and take the numbers
> >>> >>>>> for
> >>> >>>>> next 10M messages.
> >>> >>>>>
> >>> >>>>> And also try to test with number of back end servers.
> >>> >>>>>
> >>> >>>>
> >>> >>>> Yes, I'll work on this
> >>> >>>>
> >>> >>>> Thanks
> >>> >>>> Suho
> >>> >>>>
> >>> >>>>>
> >>> >>>>> thanks,
> >>> >>>>> Amila.
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> On Wed, Feb 8, 2012 at 9:25 PM, Suhothayan Sriskandarajah
> >>> >>>>> <[email protected]> wrote:
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> According to the decisions made at the architecture mailing list
> >>> >>>>>> on
> >>> >>>>>> the subject "Serializing generic Siddhi events using Thrift",
> >>> >>>>>> I did some improvements to the code base of Agent component and
> >>> >>>>>> did a
> >>> >>>>>> performance testing.
> >>> >>>>>>
> >>> >>>>>> Here I did the tests by sending total of 1 million and 10
> million
> >>> >>>>>> events using for loop,
> >>> >>>>>> in both cases I have sent events using 1,2,5,10 & 20 Clients.
> >>> >>>>>>
> >>> >>>>>> The results are as follows
> >>> >>>>>>
> >>> >>>>>>           1M              10M
> >>> >>>>>> 1      245118.1    269328.8
> >>> >>>>>> 2      517509.1    739699.7
> >>> >>>>>> 5      585823.1    923986.7
> >>> >>>>>> 10    345582.3    418865.7
> >>> >>>>>> 20    285008.6    368881.2
> >>> >>>>>>
> >>> >>>>>> I have also attached the performance graph
> >>> >>>>>>
> >>> >>>>>> Regards
> >>> >>>>>> Suho
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> --
> >>> >>>>>> S. Suhothayan
> >>> >>>>>> Software Engineer,
> >>> >>>>>> Data Technologies Team,
> >>> >>>>>> WSO2, Inc. http://wso2.com
> >>> >>>>>> lean.enterprise.middleware.
> >>> >>>>>>
> >>> >>>>>> email: [email protected] cell: (+94) 779 756 757
> >>> >>>>>> blog: http://suhothayan.blogspot.com/
> >>> >>>>>> twitter: http://twitter.com/suhothayan
> >>> >>>>>> linked-in: http://lk.linkedin.com/in/suhothayan
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> --
> >>> >>>>> Amila Suriarachchi
> >>> >>>>>
> >>> >>>>> Software Architect
> >>> >>>>> WSO2 Inc. ; http://wso2.com
> >>> >>>>> lean . enterprise . middleware
> >>> >>>>>
> >>> >>>>> phone : +94 71 3082805
> >>> >>>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> --
> >>> >>>> S. Suhothayan
> >>> >>>> Software Engineer,
> >>> >>>> Data Technologies Team,
> >>> >>>> WSO2, Inc. http://wso2.com
> >>> >>>> lean.enterprise.middleware.
> >>> >>>>
> >>> >>>> email: [email protected] cell: (+94) 779 756 757
> >>> >>>> blog: http://suhothayan.blogspot.com/
> >>> >>>> twitter: http://twitter.com/suhothayan
> >>> >>>> linked-in: http://lk.linkedin.com/in/suhothayan
> >>> >>>>
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Regards,
> >>> >>>
> >>> >>> Tharindu
> >>> >>>
> >>> >>> blog: http://mackiemathew.com/
> >>> >>> M: +94777759908
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Amila Suriarachchi
> >>> >>
> >>> >> Software Architect
> >>> >> WSO2 Inc. ; http://wso2.com
> >>> >> lean . enterprise . middleware
> >>> >>
> >>> >> phone : +94 71 3082805
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > S. Suhothayan
> >>> > Software Engineer,
> >>> > Data Technologies Team,
> >>> > WSO2, Inc. http://wso2.com
> >>> > lean.enterprise.middleware.
> >>> >
> >>> > email: [email protected] cell: (+94) 779 756 757
> >>> > blog: http://suhothayan.blogspot.com/
> >>> > twitter: http://twitter.com/suhothayan
> >>> > linked-in: http://lk.linkedin.com/in/suhothayan
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> ============================
> >>> Srinath Perera, Ph.D.
> >>>   Senior Software Architect, WSO2 Inc.
> >>>   Visiting Faculty, University of Moratuwa
> >>>   Member, Apache Software Foundation
> >>>   Research Scientist, Lanka Software Foundation
> >>>   Blog: http://srinathsview.blogspot.com/
> >>>   Photos: http://www.flickr.com/photos/hemapani/
> >>>  Phone: 0772360902
> >>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi
> >>
> >> Software Architect
> >> WSO2 Inc. ; http://wso2.com
> >> lean . enterprise . middleware
> >>
> >> phone : +94 71 3082805
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Tharindu
> >
> > blog: http://mackiemathew.com/
> > M: +94777759908
> >
>
>
>
> --
> ============================
> Srinath Perera, Ph.D.
>   Senior Software Architect, WSO2 Inc.
>   Visiting Faculty, University of Moratuwa
>   Member, Apache Software Foundation
>   Research Scientist, Lanka Software Foundation
>   Blog: http://srinathsview.blogspot.com/
>   Photos: http://www.flickr.com/photos/hemapani/
>  Phone: 0772360902
>



-- 
Regards,

Tharindu

blog: http://mackiemathew.com/
M: +94777759908
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to