Re: [Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-25 Thread Isuru Perera
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

Re: [Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-20 Thread Sajith Ravindra
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

Re: [Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-20 Thread Grainier Perera
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 wrote: > You have not answered my Qn > > whats the impact on this when it comes to Si

Re: [Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-20 Thread Sriskandarajah Suhothayan
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 wrote: > Hi Granier, Suho > > The memory calculation will be a time consuming issue since it has to > traverse through the complete object t

Re: [Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-20 Thread Sajith Ravindra
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 ma

Re: [Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-20 Thread Sriskandarajah Suhothayan
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 wrote: > Curre

[Dev] Handling time-consuming processes within Carbon Metrics Gauges

2016-01-19 Thread Grainier Perera
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 f