[match] add caching layer to significantly improve performance by up to 100x #21694
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks @nekrich. Nice PR here. I don't mind the large PR. Will look into this during the week. |
nekrich
force-pushed
the
feat/match-speed
branch
3 times, most recently
from
7d19210
to
d8ae5a4
Compare
nekrich
changed the title
nekrich
changed the title
nekrich
force-pushed
the
feat/match-speed
branch
from
d8ae5a4
to
00639f2
Compare
lacostej
reviewed
Dec 6, 2023
lacostej
approved these changes
Dec 11, 2023
rogerluan
reviewed
Dec 12, 2023
There was a problem hiding this comment.
This PR is awesome! I only did a partial review so far though 🙏 but the improvements you've observed are game-changing, thanks for this!!
I didn't have the time to go through the entire PR atm, but I have a few questions:
- Is the cache persistent (e.g. on disk)? If so, what's the persistency scope (e.g. is it valid throughout different fastlane action calls of a single lane, or different fastlane lane calls?
- What is the cache bursting logic?
Again thanks for all the effort you put in this PR, I'm glad it solved the performance issues you had and excited for other people to be able to access this! 🙌
rogerluan
changed the title
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
|
milch
reviewed
Dec 12, 2023
milch
approved these changes
Dec 13, 2023
|
🚀! Nice PR @nekrich. Thanks @milch @rogerluan :) |
5 tasks
|
@nekrich I'm experiencing an issue with the error message "cached_profiles parameter must be a non-empty array of Spaceship::ConnectAPI::Profile" after upgrading to fastlane version 2.218.0. I had to revert to version 2.217.0 to resolve the issue. |
@thanhcuong1990 , I'll look into in in a couple of hours. Can you please tell what auth type you use: Keys or login and password? |
I used |
|
The same issue. I'm using *.p8 key |
|
@viktor-savchik-idf , @thanhcuong1990 can you please check if the fix works nekrich:fix/sigh-cache-parameters-validation? Gemfile: |
|
@nekrich yes, it works |
|
@nekrich but when repeating the same command, there is another issue. |
6 tasks
|
@viktor-savchik-idf , can you please share the options you use to run the match action? I'm interested in all force_* parameters, the readonly flag and profile type. Thanks. |
We started recieving this error while trying to create apple profile via fastlane 2.218.0 using the command |
@nekrich Here is the complete action, the lane :certificates_dev do
api_key = app_store_connect_api_key_creator
register_devices(devices_file: "./devices.txt", api_key: api_key)
match(
app_identifier: ["id.one", "id.two", "id.three"],
api_key: api_key,
type: "development",
force_for_new_devices: true,
template_name: "ApplePay In-App Provisioning Distribution",
)
end |
|
Hi, Triggered by following action: EDIT: |
@nekrich Confirmed, it works for me. |
|
Wow! I tried that right now with version 2.219.0 and for our 60+ apps this is a pure gamechanger 🎉 Thank you so much for this update 👍 Here are our benchmarks: matrix-codesigning.sh is the script which runs fastlane match for development/appstore for each of our 60+ apps. |
SubhrajyotiSen
pushed a commit
to KeepTruckin/fastlane
that referenced
this pull request
Jan 17, 2024
…to 100x (fastlane#21694) * [match] increase match speed with caching * chore: skip new profile validation * chore: don’t install a nonexistent profile * chore: code readability improvements * chore: improve cert & device difference * chore: fix variable naming * chore: remove redundant var init * chore: check for unique profiles * fix: typo * chore: match portal bundle id fetcher expect only arrays * fix: only uuids with one hyphen supported for silicon macs * chore: add comment about cert type downcasing Co-authored-by: Roger Oba <rogerluan.oba@gmail.com> * chore: use standard syntax for multiline blocks * chore: remove empty it * chore: update cache returns * chore: extra check for cached certs after reset --------- Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
bundle exec rspecfrom the root directory to see all new and existing tests passbundle exec rubocop -ato ensure the code style is validci/circlecibuilds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)Hi.
Problem
We have 112 provisioning profiles. And running match not in
readonlymode takes a lot of time for us.I've made a Faraday middleware to count requests, fetch time, and the amount of passed data.
I saw many redundant fetches: profiles, certificates, bundle IDs, and devices fetched for each
app_identifierand some of them several times.tl;dr; The cached version of the match installs all 112 profiles with cert and device checks as fast as the current version manages to check and install just one development profile with the same parameters.
Description
Introduce cache and fetcher for match. We must save the state of profiles, certificates, bundle IDs, and devices. I've looked at what information changes when the match is executed and what is static.
With this, I see that caching will not bring a lot of headaches, and there will be no cache inconsistency. And introducing cache on the instance level will probably bring more good than bad.
Another good thing is that the match is executed with strict parameters: type and platform. And we can write better filters for fetching certificates and profiles.
Results (x100 😅)
Stats per url
Before:
{ "https://api.appstoreconnect.apple.com/v1/bundleIds": { "duration": 85.95213599999997, "size": 285596, "calls_count": 112 }, "https://api.appstoreconnect.apple.com/v1/certificates": { "duration": 282.9322100000001, "size": 12128325, "calls_count": 244 }, "https://api.appstoreconnect.apple.com/v1/profiles": { "duration": 4370.683801999995, "size": 2687726458, "calls_count": 1258 }, "https://api.appstoreconnect.apple.com/v1/devices": { "duration": 218.01276800000005, "size": 2287600, "calls_count": 280 } }After:
{ "https://api.appstoreconnect.apple.com/v1/bundleIds": { "duration": 9.408271000000001, "size": 199607, "calls_count": 9 }, "https://api.appstoreconnect.apple.com/v1/certificates": { "duration": 5.092039, "size": 378884, "calls_count": 5 }, "https://api.appstoreconnect.apple.com/v1/profiles": { "duration": 14.223327999999999, "size": 16328383, "calls_count": 5 }, "https://api.appstoreconnect.apple.com/v1/devices": { "duration": 1.850342, "size": 38735, "calls_count": 2 } }Solution
This PR.
To ease the review, I can split it into 5 smaller PRs:
device_count_different?andcertificate_count_different?to a new file.As for me, making separate PRs into the main branch makes almost no sense. I'm a fan of a feature branch but not a maintainer 😅. If you are ready for one biggie, please let me know.
Please tell me if my solution can be merged into the fastlane, and what strategy of PRs you would like to use.
PS. I want to thank @PaulTaykalo for his #21016 PR, which I included in this one. Paul, I hope you don't mind 😉.