On Thu, Mar 31, 2011 at 6:51 AM, Jorge Infante Osorio <jorg...@uci.cu>wrote:
> Hi Manisha, can you tell us the technical characteristic of the machine you > use to made the test? > > Do you made this test for more complicate scenarios, UT over HTTPS security > for example? > > Hi Jorge, This test was performed on the following environment. Operating system : Linux 2.6.32-28-generic Java version: 1.6.0_21 Browser Version : Firefox 3.6.13 Carbon Version : wso2as-4.1.0-SNAPSHOT / March 28 And this perf test was carried on a simple Axis2 service that comes default with the WSO2 App Server, i.e. the 'Version' service. The purpose of this test was to check whether there is any effect on performance with the changes done by Azeez by Migrating to Embedded Tomcat 7 on the Carbon platform. Therefore we did not test all the scenario combinations. And you will see there is NO performance degradation at all and a considerable performance improvement in processing. Thanks. Regards, Manisha > Thanks, > Jorge. > > > De: carbon-dev-boun...@wso2.org [mailto:carbon-dev-boun...@wso2.org] En > nombre de Manisha Gayathri > Enviado el: lunes, 28 de marzo de 2011 6:17 > Para: Afkham Azeez > CC: carbon-dev@wso2.org > Asunto: Re: [Carbon-dev] Performance issue in request processing > > > On Mon, Mar 28, 2011 at 12:14 PM, Manisha Gayathri <mani...@wso2.com> > wrote: > Hi Azeez, > > We re-did the perf test on the "Version" service deployed in AS. Since the > latest available trunk build is on March 21, took a new AS pack from > SupunM. > > The 2 server instances selected are as follows. > 1. Released AS (wso2appserver-4.0.0) > 2. AS in trunk (wso2appserver-4.1.0-SNAPSHOT) > > The test was performed using Java Bench with passing the following > parameters for each of the server instances above > > -jar benchmark.jar -p SoapRequest.xml -n 1000 -c 50 -k -H > "SOAPAction:urn:getVersion" -T "text/xml;charset=UTF-8" > http://10.100.0.166:9763/services/Version > > > > n=1000 > c=50 > Soap request message size = 137 bytes > > The result set is attached below. > > > Throughput (#/sec) -mean > > During the test we observed that there is no particular difference between > using the protocols HTTP_11 or HTTP_11_NIO > > Time per request (ms) > > > Analyzing the above results, we can observe a huge performance improvement > in the current trunk after the migration to Tomcat 7 and relevant fixes. > > > Hi all, > > The above "unbelievable" kind of results were due to the difference of > testing environments. The AS 4.0.0 Released version has been tested in a > different machine to what I have tested the AS 4.1.0 SNAPSHOT. > > Following are the real results generated in the same environments. > > Throughput (#/sec) -mean > > > Time per request (ms) > > > Still there is a performance improvement in the current trunk. Apologies if > I disappointed any of you. :( > > Thanks. > Regards, > Manisha > > Thanks. > Regards, > Manisha > > On Thu, Mar 24, 2011 at 3:10 PM, Charitha Kankanamge <chari...@wso2.com> > wrote: > Waiting for a AppServer pack from local builder. The newest one it has is > 21st build. > > Regards > Charitha > > On Thu, Mar 24, 2011 at 4:25 AM, Senaka Fernando <sen...@wso2.com> wrote: > Hi Azeez, > On Wed, Mar 23, 2011 at 4:33 PM, Afkham Azeez <az...@wso2.com> wrote: > > On Wed, Mar 23, 2011 at 4:23 PM, Senaka Fernando <sen...@wso2.com> wrote: > > On Wed, Mar 23, 2011 at 3:54 PM, Afkham Azeez <az...@wso2.com> wrote: > I have fixed part 2 of this performance issue. Senaka is working on part 1. > > Done. > > Cool. Have you got the profiling results comparison? > > Yes, I profiled the number of DB calls made from the server with and > without > the patch, and we have a fair gain, even at the start-up. I'm certain that > the numbers would've suggested a much better gain if we were to compare the > performance of a load test. > > > Without the patch, 236 connections were created, and 772 DB calls were > made. > There were 182 resourceExists calls. With the patch, 141 connections were > created, and 571 DB calls were made. There were 77 resourceExists calls. > Further to this, the server start-up time has improved. It takes around 15s > until the registry has been loaded (ok we need to fix that too, Atomikos + > LDAP integration is the direct cause to this lag). And from there onwards, > its 4s compared to 7-8s once the patch is applied. > > So, the combination of the fixes done by you and me, prove to be effective > even in the most simplest form. Let's wait for an update on the load test > front. > > Thanks, > Senaka. > > > Thanks, > Senaka. > > With my fixes, the performance figures are back to normal. Charitha, please > test with a nightly build of AppServer and confirm. > > On Wed, Mar 23, 2011 at 2:26 PM, Afkham Azeez <az...@wso2.com> wrote: > > On Wed, Mar 23, 2011 at 2:16 PM, Afkham Azeez <az...@wso2.com> wrote: > > On Wed, Mar 23, 2011 at 2:10 PM, Senaka Fernando <sen...@wso2.com> wrote: > Hi all, > On Wed, Mar 23, 2011 at 1:35 PM, Afkham Azeez <az...@wso2.com> wrote: > realmService was null in the previous release because we are using H2, and > before the Registry/UM API separation, we were not able to have auth > support > for webapps because we had to create two DB connections, which was not > possible then with H2, but now with the API separation and a single DB > connection, we are able to support it. Due to this reason, the registry > perf > bug has surfaced. Registry team, we need your help to fix this :) > > OK, now we understand the problem. So, this has been there since 3.1.0 > actually, but it did not surface due to another bug, which has been fixed. > As discussed offline with Azeez, we need to make two fixes to solve this > properly. > > 1. Get rid of the unwanted DB calls during the initialization of the > UserRegistry (basically the creation of the cluster lock table etc). > > 2. Load the UserRegistry instances only at the first access, and not when > we > initially add it to the CarbonContext. > > I will implement Lazy loading proxy objects to handle this so that the > registry objects are created only when they are required. This will save a > lot of memory as well. Thanks Senaka for suggesting this solution. > > Going to call this GhostRegistry ;) spoooooky > > > Thanks, > Senaka. > > On Wed, Mar 23, 2011 at 1:30 PM, Afkham Azeez <az...@wso2.com> wrote: > I profiled the previous release, AppServer 4.0 just now. It works fine only > because the registryService.getConfigSystemRegistry(tenantId) > & registryService.getGovernanceSystemRegistry(tenantId) methods never get > invoked in the previous release, if the userRealmService is null. That > seems > to be a bug in the previous release. So, this perf issue never surfaced in > the old release because of a potential bug > > The root cause of this perf issue is in the Registry, as can be seen in the > previous JProfiler CPU profiling diagram I sent. > > Azeez > > On Wed, Mar 23, 2011 at 1:06 PM, Afkham Azeez <az...@wso2.com> wrote: > > On Wed, Mar 23, 2011 at 1:00 PM, Senaka Fernando <sen...@wso2.com> wrote: > > On Wed, Mar 23, 2011 at 12:56 PM, Afkham Azeez <az...@wso2.com> wrote: > I looked at the previous 3.1.0 code and did not find any place where we > cache the CarbonContext. Like HttpReqeust, Response etc. I think it is > perfectly OK to create CarbonContext instances per request. But the > creation > of it should be fast. > > OK, we need to compare 3.1.0 and 3.2.0 (profile them both I mean) and see > whether we can find what's the cause of this slowness, as this issue is due > to something that has changed between 3.1.0 and today. > > The API separation was a major change. > > > Thanks, > Senaka. > > On Fri, Mar 11, 2011 at 10:12 PM, Senaka Fernando <sen...@wso2.com> wrote: > Hi Azeez, > > OK, so it seems to be wrong to be reconstructing the carbon context over > and > over again, for each request that comes in. This was cached in some scope > (session or context), making this a one-time overhead. Did this change from > 3.1.0 to 3.2.0 for some reason? > > Thanks, > Senaka. > On Fri, Mar 11, 2011 at 3:54 PM, Afkham Azeez <az...@wso2.com> wrote: > As can be seen in the JProfiler screenshot, there getRegistry methods are > introducing a big overhead. > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > _______________________________________________ > Carbon-dev mailing list > Carbon-dev@wso2.org > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > > > -- > Senaka Fernando > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 > Linked-In: http://www.linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Senaka Fernando > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 > Linked-In: http://www.linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Senaka Fernando > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 > Linked-In: http://www.linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Senaka Fernando > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 > Linked-In: http://www.linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > > > > > -- > Senaka Fernando > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 > Linked-In: http://www.linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > > > > _______________________________________________ > Carbon-dev mailing list > Carbon-dev@wso2.org > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
