Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Service#power_state] Avoid update if values match #18445

Conversation

NickLaMuro
Copy link
Member

As part of the getter for Service#power_state, avoid calling an update_attributes if the value is already what we are going to update it to.

This avoids not only some SQL queries, but some YAML serialization that slows down API requests and reports that use this virtual_attribute.

Note: The changes that introduced the update_attributes in power_state can be found here:

#12963

And provides some context as to why I kept it instead of removing that update_attributes.

Benchmarks:

These benchmarks are done against the API doing the following request:

url: /api/services
attributes:
  expand: resources
  attributes:
    -picture
    - picture.image_href
    - chargeback_report
    - evm_owner.userid
    - v_total_vms
    - power_state
    - all_service_children
    - tags
  filter[]:      ancestry=null
  sort_by:       created_at
  sort_options:  nil
  sort_order:    desc
  limit:         20
  offset:        0

And about half of the attributes need to trigger an update. Because of the way the code is configured and that the metrics were taken against a database that is detached from the provider (the power_states_match? call is consistent every time as a result), this happens consistently across runs.

Before

|   ms | queries | query (ms) | rows |
| ---: |    ---: |       ---: | ---: |
| 2060 |     322 |        152 | 1627 |
|  799 |     321 |      132.5 |  196 |
|  839 |     321 |      134.2 |  196 |

After

|   ms | queries | query (ms) | rows |
| ---: |    ---: |       ---: | ---: |
| 1976 |     290 |        164 | 1625 |
|  675 |     289 |      128.4 |  194 |
|  686 |     289 |      128.4 |  194 |

Also, if you combine this change with the changes is ManageIQ/manageiq-api#557 you will get the following improvements

|   ms | queries | query (ms) | rows |
| ---: |    ---: |       ---: | ---: |
| 1819 |     230 |      143.5 | 1590 |
|  637 |     229 |      131.7 |  159 |
|  624 |     229 |      132.7 |  159 |

Links

As part of the getter for `Service#power_state`, avoid calling an
`update_attributes` if the value is already what we are going to update
it to.

This avoids not only some SQL queries, but some YAML serialization that
slows down API requests and reports that use this `virtual_attribute`.

Benchmarks:
-----------

These benchmarks are done against the API doing the following request:

```
url: /api/services
attributes:
  expand: resources
  attributes:
    -picture
    - picture.image_href
    - chargeback_report
    - evm_owner.userid
    - v_total_vms
    - power_state
    - all_service_children
    - tags
  filter[]:      ancestry=null
  sort_by:       created_at
  sort_options:  nil
  sort_order:    desc
  limit:         20
  offset:        0
```

And about half of the attributes need to trigger an update.  Because of
the way the code is configured and that the metrics were taken against a
database that is detached from the provider (the `power_states_match?`
call is consistent every time as a result), this happens consistently
across runs.

**Before**

|   ms | queries | query (ms) | rows |
| ---: |    ---: |       ---: | ---: |
| 2060 |     322 |        152 | 1627 |
|  799 |     321 |      132.5 |  196 |
|  839 |     321 |      134.2 |  196 |

**After**

|   ms | queries | query (ms) | rows |
| ---: |    ---: |       ---: | ---: |
| 1976 |     290 |        164 | 1625 |
|  675 |     289 |      128.4 |  194 |
|  686 |     289 |      128.4 |  194 |
Copy link
Member

@kbrock kbrock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I'll give @syncrou a chance to comment, otherwise plan on merging

Copy link
Contributor

@syncrou syncrou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@kbrock kbrock merged commit 0837d2c into ManageIQ:master Feb 13, 2019
@kbrock kbrock added the core label Feb 13, 2019
@agrare agrare added this to the Sprint 105 Ending Feb 18, 2019 milestone Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants