You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Chiradeep Vittal <Ch...@citrix.com> on 2013/03/04 23:38:30 UTC
Re: [ACS41][QA] Test plan for List API Performance Optimization
On 2/22/13 10:24 AM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>Hi,
>
>I've posted a test plan for tracking the performance numbers for the set
>of List APIs which were optimized as mentioned in
>https://issues.apache.org/jira/browse/CLOUDSTACK-527
>Test plan is here:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/List+API+Performanc
>e+Test+Plan
>
>Please take a look and post comments if any.
>
>Thanks,
>Sowmya
Thanks for this. Performance involves a number of different factors and
changing any one of them can result in dramatically different results.
So
Client -> client http library -> client OS -> client cpu -> client nic
-> network switch -> server nic -> server cpu -> server OS -> jvm -> tomcat
-> cloudstack -> server OS -> nic -> server nic -> network switch
-> DB nic -> DB CPU -> DB OS -> mysql -> DB OS -> DB hard drive
So, a lot of variables, some more pertinent than others.
One tip is to make sure that MySQL runs entirely from memory, so
if you set innodb_buffer_pool_size [1] to the maximum possible,
queries will likely run entirely from RAM and isolate any hard drive
dependency.
Another tip is to make sure that there is no other traffic on the network.
Another tip is to instrument the server with a tool like AppDynamics[2] or
NewRelic [3]. This will help us isolate the bottlenecks within the
application code and give us useful statistics.
[1]<http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_in
nodb_buffer_pool_size>
[2] http://info.appdynamics.com/AppDynamicsLiteJavaNet.html
[3] http://newrelic.com/
RE: [ACS41][QA] Test plan for List API Performance Optimization
Posted by Sowmya Krishnan <so...@citrix.com>.
Thanks for the helpful pointers Chiradeep! I'll keep these in mind during the further performance runs.
On the innodb_buffer_pool_size, I usually set it to 80% of the RAM size for all my runs.
Thanks for the pointers on the tools as well - I'll try out these for my next performance run and will include details in the test plan too once I start using.
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Tuesday, March 05, 2013 4:09 AM
> To: cloudstack-users@incubator.apache.org; cloudstack-
> dev@incubator.apache.org
> Subject: Re: [ACS41][QA] Test plan for List API Performance Optimization
>
>
>
> On 2/22/13 10:24 AM, "Sowmya Krishnan" <so...@citrix.com>
> wrote:
>
> >Hi,
> >
> >I've posted a test plan for tracking the performance numbers for the
> >set of List APIs which were optimized as mentioned in
> >https://issues.apache.org/jira/browse/CLOUDSTACK-527
> >Test plan is here:
> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/List+API+Perform
> >anc
> >e+Test+Plan
> >
> >Please take a look and post comments if any.
> >
> >Thanks,
> >Sowmya
>
> Thanks for this. Performance involves a number of different factors and
> changing any one of them can result in dramatically different results.
> So
>
> Client -> client http library -> client OS -> client cpu -> client nic
> -> network switch -> server nic -> server cpu -> server OS -> jvm ->
> -> tomcat cloudstack -> server OS -> nic -> server nic -> network switch
> -> DB nic -> DB CPU -> DB OS -> mysql -> DB OS -> DB hard drive
>
> So, a lot of variables, some more pertinent than others.
>
> One tip is to make sure that MySQL runs entirely from memory, so if you set
> innodb_buffer_pool_size [1] to the maximum possible, queries will likely run
> entirely from RAM and isolate any hard drive dependency.
>
> Another tip is to make sure that there is no other traffic on the network.
>
> Another tip is to instrument the server with a tool like AppDynamics[2] or
> NewRelic [3]. This will help us isolate the bottlenecks within the application code
> and give us useful statistics.
>
> [1]<http://dev.mysql.com/doc/refman/5.1/en/innodb-
> parameters.html#sysvar_in
> nodb_buffer_pool_size>
> [2] http://info.appdynamics.com/AppDynamicsLiteJavaNet.html
> [3] http://newrelic.com/
RE: [ACS41][QA] Test plan for List API Performance Optimization
Posted by Sowmya Krishnan <so...@citrix.com>.
Thanks for the helpful pointers Chiradeep! I'll keep these in mind during the further performance runs.
On the innodb_buffer_pool_size, I usually set it to 80% of the RAM size for all my runs.
Thanks for the pointers on the tools as well - I'll try out these for my next performance run and will include details in the test plan too once I start using.
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Tuesday, March 05, 2013 4:09 AM
> To: cloudstack-users@incubator.apache.org; cloudstack-
> dev@incubator.apache.org
> Subject: Re: [ACS41][QA] Test plan for List API Performance Optimization
>
>
>
> On 2/22/13 10:24 AM, "Sowmya Krishnan" <so...@citrix.com>
> wrote:
>
> >Hi,
> >
> >I've posted a test plan for tracking the performance numbers for the
> >set of List APIs which were optimized as mentioned in
> >https://issues.apache.org/jira/browse/CLOUDSTACK-527
> >Test plan is here:
> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/List+API+Perform
> >anc
> >e+Test+Plan
> >
> >Please take a look and post comments if any.
> >
> >Thanks,
> >Sowmya
>
> Thanks for this. Performance involves a number of different factors and
> changing any one of them can result in dramatically different results.
> So
>
> Client -> client http library -> client OS -> client cpu -> client nic
> -> network switch -> server nic -> server cpu -> server OS -> jvm ->
> -> tomcat cloudstack -> server OS -> nic -> server nic -> network switch
> -> DB nic -> DB CPU -> DB OS -> mysql -> DB OS -> DB hard drive
>
> So, a lot of variables, some more pertinent than others.
>
> One tip is to make sure that MySQL runs entirely from memory, so if you set
> innodb_buffer_pool_size [1] to the maximum possible, queries will likely run
> entirely from RAM and isolate any hard drive dependency.
>
> Another tip is to make sure that there is no other traffic on the network.
>
> Another tip is to instrument the server with a tool like AppDynamics[2] or
> NewRelic [3]. This will help us isolate the bottlenecks within the application code
> and give us useful statistics.
>
> [1]<http://dev.mysql.com/doc/refman/5.1/en/innodb-
> parameters.html#sysvar_in
> nodb_buffer_pool_size>
> [2] http://info.appdynamics.com/AppDynamicsLiteJavaNet.html
> [3] http://newrelic.com/