On Thu, Jul 5, 2012 at 10:12 AM, Amila Maha Arachchi <[email protected]>wrote:
> 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? > In synapse we are using the nhttp transport and not dealing with tomcat, so I think this is not possible with ESB. Since we are dealing with the most sensitive part of synapse, this should be done with extreme care. I think we should look at how other matrices like latency is calculated in synapse to get an idea. Thanks, IsuruU > > 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 > > > -- *Isuru Udana* * * * Software Engineer * Integration Technologies Team, WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 3791887 blog: http://mytecheye.blogspot.com/ twitter: http://twitter.com/isudana
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
