aztfexport
aztfexport copied to clipboard
Azure
Aztfy Passes All Performance Tests
Let's define a set of performance tests to get understanding of general benchmarks and time it would take a user to import various sets of resource groups. We want to make sure that nothing is exceedingly slow while importing infrastructure for the user.
The importing time depends on the Azure API speeds, including the ARM template export API and the GET API of each resource to be imported. The time consumed by aztfy itself is limited.
Very fair, I don't think we'll be able to make significant changes before GA. Just having an idea of how long runtime tasks will take for documentation and setting expectations around total runtime is reasonable in my mind.
Can we get a benchmark of ARM template exporting from somewhere? As I noticed it takes long time when exporting ARM template for a large resource group.
@stemaMSFT In this commit: https://github.com/Azure/aztfy/pull/166/commits/2dd05eebc83dfdd4b534f455fa7d486f7c64a203, I've export two env vars, which will make the provider to skip calling the expensive RP listing API, which can increase the performance a lot.
@magodo good to know! out of curiosity, any estimate on the impact of exporting env vars?
@stemaMSFT With this change, a previously import that needs about ~10min now can finish in ~1min.
@magodo that's awesome. help me understand a basic concept here: can we enforce this for all customers? If so I think we can PR this into main (after approval) and use it moving forward.
@stemaMSFT This has already been merged in the main branch, with this can we close this issue for now?
@magodo let's hold off until we've formally defined performance tests for Aztfy before we close this issue for good.
@stemaMSFT I've locally tested for a rg in batch mode, which has following resources:
- azurerm_linux_virtual_machine.res-2
- azurerm_managed_disk.res-1
- azurerm_network_interface.res-3
- azurerm_network_security_group.res-13
- azurerm_network_security_group.res-4
- azurerm_network_security_rule.res-10
- azurerm_network_security_rule.res-11
- azurerm_network_security_rule.res-12
- azurerm_network_security_rule.res-14
- azurerm_network_security_rule.res-15
- azurerm_network_security_rule.res-16
- azurerm_network_security_rule.res-17
- azurerm_network_security_rule.res-18
- azurerm_network_security_rule.res-19
- azurerm_network_security_rule.res-20
- azurerm_network_security_rule.res-21
- azurerm_network_security_rule.res-5
- azurerm_network_security_rule.res-6
- azurerm_network_security_rule.res-7
- azurerm_network_security_rule.res-8
- azurerm_network_security_rule.res-9
- azurerm_private_dns_a_record.res-23
- azurerm_private_dns_zone.res-22
- azurerm_private_dns_zone_virtual_network_link.res-25
- azurerm_resource_group.res-0
- azurerm_subnet.res-27
- azurerm_virtual_network.res-26
It takes 2m30s to finish (most of the time takes in the API).
@magodo how reasonable time-wise would it take to have a by-resource breakdown of the overall runtime? If that'd be achievable we'd have the ability on our side to action with RP/service teams on slow runtimes for a specific resource.
I'm going to close this issue for now, assuming the 0.9.0 parallelism addresses performance issues. We can revisit if there's other issues down the road.