Yes. It's better to profile and see. I also discussed with Grainier and we think it's better to use "DEBUG" or "TRACE" level when creating the gauge for memory consumption.
In that way, we can enable these kinds of gauges in runtime only when we need. (The Carbon Metrics has a feature to support changing the configured level dynamically at runtime via a JMX operation) Thanks! On Thu, Jan 21, 2016 at 11:40 AM, Sajith Ravindra <[email protected]> wrote: > I think it will be a good idea to run several rounds of testing to see if > this memory calculation is CPU intensive. And If this is CPU intensive then > this might have an adverse affect the overall performance of CEP/Siddhi as > well when executing in a limited resource setup. > > 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 Wed, Jan 20, 2016 at 9:59 PM, Grainier Perera <[email protected]> > wrote: > >> Hi suho, >> >> It does not have any impact on Siddhi's runtime performance. It just >> affects on metrics reporting, which runs separately. >> >> Thanks, >> Grainier. >> >> On Thu, Jan 21, 2016 at 10:09 AM, Sriskandarajah Suhothayan < >> [email protected]> wrote: >> >>> You have not answered my Qn >>> >>> whats the impact on this when it comes to Siddhi's runtime performance ? >>> >>> Suho >>> >>> On Wednesday, January 20, 2016, Sajith Ravindra <[email protected]> >>> wrote: >>> >>>> Hi Granier, Suho >>>> >>>> The memory calculation will be a time consuming issue since it has to >>>> traverse through the complete object tree. IMO, we should have the option >>>> of executing matrix calculation in a separate thread and report back to the >>>> caller with the result. >>>> >>>> I think it's a valid case to have matrices which consume time/resources >>>> to calculate. Therefore, it will be a good idea to make available the >>>> option of matrix calculation to be asynchronous and report back once done >>>> in carbon metrics library it self. >>>> >>>> WDYT? >>>> >>>> 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 Wed, Jan 20, 2016 at 10:32 AM, Sriskandarajah Suhothayan < >>>> [email protected]> wrote: >>>> >>>>> I understand that Matrics reporting it getting slow. >>>>> >>>>> At the meantime whats the impact on this when it comes to Siddhi >>>>> performance ? >>>>> If Siddhi query is also getting halted for 3 sec, then this is going >>>>> to be a bigger problem. >>>>> >>>>> Suho >>>>> >>>>> On Wed, Jan 20, 2016 at 12:25 PM, Grainier Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> Currently, the memory usage calculation mechanism used on a Siddhi >>>>>> query takes around 3 seconds. Therefore, when it comes to complex flow >>>>>> with >>>>>> several of execution plans, it takes around (# of queries * 3) seconds. >>>>>> Moreover, we have integrated carbon-metrics [1] (Gauges in this scenario) >>>>>> with CEP for metrics calculation and reporting. Therefore, if we were to >>>>>> use the same mechanism within the getValue() method of carbon-metrics >>>>>> Gauges, it will increase the reporting time consumed by scheduled >>>>>> reporters >>>>>> (per iteration) by ~(# of queries * 3) seconds. That might cause issues >>>>>> such as reporters does not report according to the defined PollingPeriod, >>>>>> takes a considerable amount of time to update and render Carbon Metrics >>>>>> UI, >>>>>> etc. Therefore, is there a way to handle such time-consuming process >>>>>> within >>>>>> Carbon Metrics Gauges? >>>>>> >>>>>> Gauge.getValue() Implementation: >>>>>> >>>>>> new Gauge<Long>() { >>>>>> @Override >>>>>> public Long getValue() { >>>>>> *// Below process takes ~3 seconds.* >>>>>> ObjectGraphMeasurer.Footprint footprint = >>>>>> ObjectGraphMeasurer.measure(object); >>>>>> return MemoryMeasurerUtil.footprintSizeEstimate(footprint); >>>>>> } >>>>>> }); >>>>>> >>>>>> [1] https://github.com/wso2/carbon-metrics >>>>>> >>>>>> Thanks, >>>>>> Grainier. >>>>>> -- >>>>>> Grainier Perera >>>>>> Software Engineer >>>>>> Mobile : +94716122384 >>>>>> WSO2 Inc. | http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *S. Suhothayan* >>>>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>>>> *WSO2 Inc. *http://wso2.com >>>>> * <http://wso2.com/>* >>>>> lean . enterprise . middleware >>>>> >>>>> >>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>>>> http://lk.linkedin.com/in/suhothayan >>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>> >>>> >>>> >>> >>> -- >>> >>> *S. Suhothayan* >>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>> *WSO2 Inc. *http://wso2.com >>> * <http://wso2.com/>* >>> lean . enterprise . middleware >>> >>> >>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >>> >>> >> >> >> -- >> Grainier Perera >> Software Engineer >> Mobile : +94716122384 >> WSO2 Inc. | http://wso2.com >> lean.enterprise.middleware >> > > -- Isuru Perera Associate Technical Lead | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware about.me/chrishantha Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
