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 <saji...@wso2.com> 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 <s...@wso2.com > <javascript:_e(%7B%7D,'cvml','s...@wso2.com');>> 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 <grain...@wso2.com >> <javascript:_e(%7B%7D,'cvml','grain...@wso2.com');>> 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 | 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>*
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
