Hi Lasindu, On Thu, Jul 5, 2012 at 9:56 AM, Lasindu Vidana Pathiranage <[email protected] > wrote:
> As shankar suggested ESB & BPS are the ones which caused problems with > their internal thread pools. > I tested both CPU time and Thread live time per request per tenant for > Application Server and Data Services Server inside the > CarbonStuckThreadDetectionValve. I created few web services, web apps > and data services to test them out. Worked well in measuring both CPU > & Live time for a request. > > I was able to measure the CPU time of a BPEL process which consist of > a busy loop inside the process with the help of waruna. I captured the > CPU time inside ode/Scheduler-simple , call() method inside > SimpleScheduler class. > > With the help of KasunI and IsuruU I was able to measure the CPU time > for ESB as well. I created a class mediator which consist of a busy > loop and was able to capture the CPU time for both in/out sequences. > ServerWorker handles the requests and ClientWorker handles the > responses. I was able to capture CPU time as well as Live time per > transaction for ESB as well. Both classes contain run() methods and > its where I was able to capture the CPU time. Since ESB uses > non-blocking threads, and nhttp, it seems only way to capture the CPU > time per thread is inside the run() methods. > > Since I was able to measure the CPU time for AS, DSS, BPS, ESB for > almost all the cases, I tested out some Load tests for ESB. I sent > 100,000 echo requests to AS via a proxy from ESB. The test statistics > revealed, it may take a considerable amount of time to capture the CPU > time for each request (overhead). Since ESB mostly concern on the > performance, it might cause some latency issues if I'm to include the > code inside it. I didn't find any alternative way to capture the CPU > time per tenant/thread inside ESB either. > Please try your test without the sys outs. AFAIR there were two sys outs per one request. Please remove them and test. > > Also if I'm to proceed with this I wanted to know how I can use this > statistics to publish to BAM2. > One alternative to use the same approach as it is used in bandwidth > measuring. It has used a TransportStatistics queue in tomcat to add > the statistics and usage agent in SLive retrieves them and publishes > to BAM. Even though I can add data captured inside the tomcat valve to > a queue in tomcat.ext/transport/statistics (CpuStatisticsContainer or > whatever) I'm not sure whether I can add data from ode (BPS) or > synapse (ESB) to the same queue in tomcat. > I think you should be able to store them in the same way. But then we have a problem. We cannot add these code/patches to synapse or ode. Can we? Regards, AmilaM. > > > Thanks, > Lasindu > -- *Amila Maharachchi* Technical Lead Member, Management Committee - Cloud & Platform TG WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
