Look good Isuru!!

On Thu, Nov 13, 2014 at 6:58 PM, Isuru Perera <[email protected]> wrote:

> Hi all,
>
> I played with following performance libraries.
>
>    - Metrics
>    - Parfait
>    - JAMon
>    - Java Simon
>    - Perf4J
>
> I did a simple comparison and blogged [1].
>
> As Srinath mentioned, the Metrics library is more suitable for this
> proposal.
>
> It supports various measuring instruments like Meters, Counters,
> Histograms, Timers etc.
>
> Metrics supports JMX reporting and we should be able to write our own
> reporting implementations easily. We can use a reporting implementation to
> integrate with BAM.
>
> There is no support to enable/disable metrics. Since this is an important
> feature for us, I'm thinking of introducing a custom component for
> performance monitoring.
>
> The custom component will support to enable/disable performance monitoring
> via system property and JMX. The WSO2 components will use the new
> performance monitoring component and we will be using the Metrics only
> inside the new component.
>
> I'm working on this and for testing we need to select a WSO2 product. I'm
> thinking of adding the performance probes to WSO2 API Manager first. Since
> WSO2 CEP is also mentioned, we can have a look at that also.
>
> Please share any suggestions or feedback.
>
> I will update the thread once I create the initial design.
>
> Thanks!
>
> Best Regards,
>
> [1]
> http://isuru-perera.blogspot.com/2014/11/java-performance-monitoring-libraries.html
>
>
> On Mon, Sep 29, 2014 at 10:00 AM, Srinath Perera <[email protected]> wrote:
>
>> Thanks Thomas!!
>>
>> Paul, I looked at all 3 and really liked what Thomas sent (
>> https://dropwizard.github.io/metrics/3.1.0/getting-started/). Licence is
>> Apache 2.
>>
>> I think I will try this out with a training project.
>>
>> --Srinath
>>
>> On Sat, Sep 27, 2014 at 11:37 AM, Thomas Wieger <
>> [email protected]> wrote:
>>
>>> please have a look on the metrics lib, which quite nicely provides
>>> support for capturing different kinds of statistics. see
>>> https://dropwizard.github.io/metrics/3.1.0/
>>>
>>>
>>> regards,
>>>
>>> thomas
>>>
>>> Am Freitag, 26. September 2014 schrieb Sajith Ravindra :
>>>
>>>
>>>> IMHO, CEP is another product where this kind of probes can  be really
>>>> useful as we have to deal with performance related requirements. As there's
>>>> a major refactoring going on in siddhi I think we can we plant probes like
>>>> this into the Siddhi engine. It will be useful to evaluate the re-factored
>>>> Sindhi engines performance as well as to figure out performance bottlenecks
>>>> in the future.
>>>>
>>>>
>>>> Thanks
>>>> *,Sajith Ravindra*
>>>> Senior Software Engineer
>>>> WSO2 Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 77 2273550
>>>> blog: http://sajithr.blogspot.com/
>>>> <http://lk.linkedin.com/pub/shani-ranasinghe/34/111/ab>
>>>>
>>>> On Fri, Sep 26, 2014 at 8:38 AM, Srinath Perera <[email protected]>
>>>> wrote:
>>>>
>>>>> We have some pretty nice probes already in ESB, that let you look into
>>>>> what is going in the same running in production.  I think we need to do
>>>>> this generally and build it to other products. That should reduce time we
>>>>> spent debugging issues significantly.
>>>>>
>>>>> My proposal is to build a probe Lib that looks like following.
>>>>>
>>>>> There are two kinds of things you need to collect.
>>>>>
>>>>>    1. Throughput at give point of code (how fast calls goes though)
>>>>>    2. Latency between two points.
>>>>>
>>>>>
>>>>> We will have two types of Probes. Code would look like following.
>>>>>
>>>>> Probe probe = new Probe("Name", "throughput", timeDuration);
>>>>> ..
>>>>> probe.recordThroughput();
>>>>>
>>>>> Probe probe = new Probe("Name", "latency", timeDuration, logLevel);
>>>>> ...
>>>>> long id = probe.startTicking() // this so same probe can be used by
>>>>> many threads
>>>>> ...
>>>>> probe.endTicking(id);
>>>>>
>>>>> Probe will summarise data over given duration and expose. We need
>>>>>
>>>>>
>>>>>    1. JMX bean
>>>>>    2. BAM Agent
>>>>>    3. Can turn on, off via JMX agent or via System property
>>>>>    4. Have Tool Box
>>>>>    5. Have in product UI
>>>>>    6. Can configured to write data to logs
>>>>>
>>>>> Each probe should be very small and should be able to create thousands
>>>>> without much effect. (e.g. create one for each mediator type)
>>>>>
>>>>> WDYT?
>>>>>
>>>>> --Srinath
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ============================
>>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>>>> Site: http://people.apache.org/~hemapani/
>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>> Phone: 0772360902
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>
>>
>> --
>> ============================
>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>> Site: http://people.apache.org/~hemapani/
>> Photos: http://www.flickr.com/photos/hemapani/
>> Phone: 0772360902
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
>



-- 
============================
Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
Site: http://people.apache.org/~hemapani/
Photos: http://www.flickr.com/photos/hemapani/
Phone: 0772360902
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to