Mailing-List: contact cloudstack-issues-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Date: Mon, 4 Mar 2013 15:47:13 +0000 (UTC)
From: "Chip Childers (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12635141.1362411582252.375661.1362412033372@arcas>
In-Reply-To: <JIRA.12635141.1362411582252@arcas>
References: <JIRA.12635141.1362411582252@arcas>
Subject: [jira] [Updated] (CLOUDSTACK-1499) ListAPI Performance for few APIs
 not as good as it was before API optimization
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CLOUDSTACK-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chip Childers updated CLOUDSTACK-1499:
--------------------------------------

    Priority: Critical  (was: Major)

Upgrading the severity of this to Critical.  The numbers listed seem exceptionally slow, and I'd hate to release in this state.

After triage, if the findings show that this is actually not as much of a problem (or is possibly environmental), we can discuss downgrading it.

-chip
                
> ListAPI Performance for few APIs not as good as it was before API optimization
> ------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-1499
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1499
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API
>    Affects Versions: 4.1.0
>         Environment: CentOS 6.3
>            Reporter: Sowmya Krishnan
>            Assignee: Min Chen
>            Priority: Critical
>             Fix For: 4.1.0
>
>
> In comparison to the numbers before API Optimization was done, the numbers after Optimization aren't good for few APIs. 
> Configuration Details:
> (Using simulator set up)
> (Advanced zone)
> Accounts: 2117
> Hosts: 1986
> Users: 2116
> Virtual machines: 3299
> Server configurations:
> Management Server :
> =================
> 8 proc Intel(R) Xeon(R) CPU E5620  @ 2.40GHz processor
> CentOS release 6.3 (Final)
> Database: 
> ========
> 8 proc Intel(R) Xeon(R) CPU E5620  @ 2.40GHz processor
> Red Hat Enterprise Linux Server release 6.2 (Santiago)
> MySQL-server-5.5.21-1.linux2.6.x86_64 (InnoDB engine)
> Example 1:
> listUsers: (4.1 numbers) - with 2K users
> ===============================
> pagesize = 100: 0m38.827s
> pagesize = 800: 6m2.565s
> pagesize = 1500: 6m48.526s
> pagesize = 3000: 14m34.643s (returned 2116=max objects)
> These are the numbers *before optimization* for listUsers with 4K users
> ========================================================
> pagesize = 100: 13 s
> pagesize = 1000 : 49 s
> pagesize = 5000 : 136 s (returned 4K = max objects)
> Example 2:
> listStoragePools: (4.1 numbers) - with 248 storage pools
> =============================================
> pagesize = 100: 3m32.399s
> pagesize = 1000 : didn't complete by 20 mins
> These are the numbers *before optimization* for listStoragePools with 224 objects
> =================================================================
> pagesize = 100: 5s
> pagesize = 1000: 15s
> Although the DB server which was used for the "before optimization" performance run was higher end (quad core, 8 processor), still 14 mins to return 2K objects seems too high. And StoragePools API didn't complete at the end of 20 mins.
> So far, I observed discrepancies with the above two APIs. Will include if I find more.
> Opening this ticket for more investigation on the above numbers.
> Complete results for other APIs are posted here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/List+API+Performance+Test+Execution

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira