Backlog #2338
make VM listing scale better
| Status: | Pending | Start date: | 09/26/2013 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | - |
Description
I have a need to efficiently receive specific subsets of the currently existing VMs. For example:
a) list of all VMs running on a specific hypervisor
b) list of all VMs attached to a specific virtual network
The current implementation becomes very slow & inefficient at large numbers of virtual machines, having to transfer essentially the full list of all VMs for most queries. I would recommend some additional query options that efficiently return just the wanted data, in essence changing the internal SQL queries to be more specific dependent on API query options.
Related issues
History
#1
Updated by Ruben S. Montero over 7 years ago
- Category set to Core & System
#2
Updated by Ruben S. Montero over 7 years ago
- Target version changed from Release 4.4 to Release 4.6
#3
Updated by Ruben S. Montero over 7 years ago
- Status changed from Pending to New
#4
Updated by Ruben S. Montero over 7 years ago
- Related to Backlog #2340: filter VM listing server-side added
#5
Updated by Ruben S. Montero over 7 years ago
- Tracker changed from Feature to Backlog
- Priority changed from Normal to Low
#6
Updated by Ruben S. Montero over 7 years ago
- Target version deleted (
Release 4.6)
#7
Updated by Javi Fontan over 7 years ago
It's not exactly what you've asked for but some changes are made to the codebase that will become 4.6 that will alleviate your problem:
- Big pools can be sent paginated and are parsed using SAX. This makes the parsing faster and take less memory
- It's able to use Ox library for XML parsing. This library is much faster parsing xmlrpc and its payload (the pool).
Using a newer ruby version greatly increases the speed of the tools. 2.1.0 runs much faster that 1.8.7
#8
Updated by Ruben S. Montero over 7 years ago
- Status changed from New to Pending