incubator-cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Min Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-1499) ListAPI Performance for few APIs not as good as it was before API optimization
Date Mon, 04 Mar 2013 17:19:12 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592374#comment-13592374
] 

Min Chen commented on CLOUDSTACK-1499:
--------------------------------------

Sowmya, I have a question, why don't we use the same hardware setup for before and after run?
From your description, "before optimization" we have been using a powerful machine for DB
server, since this feature is mainly optimizing at DB layer, a fair comparison will be better.
                
> 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

Mime
View raw message