Buforowanie potoku

Usługi Azure DevOps

Buforowanie potoków może pomóc skrócić czas kompilacji, umożliwiając ponowne wykorzystanie wyników lub pobranych zależności z jednego uruchomienia w kolejnych uruchomieniach, co pozwala ograniczyć lub uniknąć kosztów ponownego tworzenia lub pobierania tych samych plików. Buforowanie jest szczególnie przydatne w sytuacjach, gdy te same zależności są wielokrotnie pobierane na początku każdego uruchomienia. Jest to często czasochłonny proces obejmujący setki lub tysiące wywołań sieciowych.

Buforowanie może być skuteczne dla poprawy czasu budowania, pod warunkiem, że czas na przywrócenie i zapisanie pamięci podręcznej jest krótszy od czasu wytworzenia wyniku od nowa. Z tego powodu buforowanie może nie być skuteczne we wszystkich scenariuszach i może mieć negatywny wpływ na czas kompilacji.

Kiedy należy używać artefaktów czy pamięci podręcznej

Buforowanie potoków i artefakty potoku wykonują podobne funkcje, ale są przeznaczone dla różnych scenariuszy i nie powinny być używane zamiennie.

• Użyj artefaktów potoku, gdy trzeba pozyskać określone pliki utworzone w jednym zadaniu i udostępnić je innym zadaniom (a te inne zadania prawdopodobnie nie powiodą się bez nich).

• Użyj buforowania potoku, gdy chcesz poprawić czas kompilacji, ponownie używając plików z poprzednich przebiegów (a ich brak nie wpłynie na możliwość uruchomienia zadania).

Zadanie pamięci podręcznej: jak to działa

Buforowanie jest dodawane do potoku za pomocą zadania Cache. To zadanie działa jak każde inne zadanie i jest dodawane do sekcji steps zadania.

Gdy podczas przebiegu napotkano krok pamięci podręcznej, zadanie przywraca pamięć podręczną na podstawie podanych danych wejściowych. Jeśli pamięć podręczna nie zostanie znaleziona, krok zostanie ukończony i zostanie uruchomiony następny krok w zadaniu.

Po uruchomieniu wszystkich kroków zadania i założeniu pomyślnego stanu zadania specjalny "Post-job: Cache" krok jest automatycznie dodawany i wyzwalany dla każdego "przywracanie pamięci podręcznej" kroku, który nie został pominięty. Ten krok jest odpowiedzialny za zapisywanie pamięci podręcznej.

Konfiguracja zadania pamięci podręcznej

Zadanie pamięci podręcznej ma dwa wymagane argumenty: klucz i ścieżka :

• ścieżka: ścieżka folderu do buforowania. Może być ścieżką bezwzględną lub względną. Ścieżki względne są rozwiązywane względem $(System.DefaultWorkingDirectory).

• klucz: należy ustawić identyfikator pamięci podręcznej, którą chcesz przywrócić lub zapisać. Klucze składają się z kombinacji wartości ciągów, ścieżek plików lub wzorców plików, gdzie każdy segment jest oddzielony znakiem |.

• ciągi:
  Stała wartość (na przykład nazwa pamięci podręcznej lub nazwa narzędzia) lub pobrana ze zmiennej środowiskowej (na przykład bieżąca nazwa systemu operacyjnego lub bieżącego zadania)

• ścieżki plików:
  Ścieżka do określonego pliku, którego zawartość zostanie zahaszowana. Ten plik musi istnieć w momencie uruchomienia zadania. Należy pamiętać, że każdy segment klucza, który "wygląda jak ścieżka pliku", będzie traktowany jak ścieżka pliku. W szczególności obejmuje to segmenty zawierające .. Może to spowodować niepowodzenie zadania, gdy ten "plik" nie istnieje.

  Napiwek

  Aby uniknąć traktowania segmentu ciągu przypominającego ścieżkę jak ścieżka pliku, opakuj go podwójnymi cudzysłowami, na przykład: "my.key" | $(Agent.OS) | key.file

• wzorce plików :
  Lista wzorców wieloznacznych w stylu glob oddzielonych przecinkami, które muszą pasować do co najmniej jednego pliku. Na przykład:

  • **/yarn.lock: wszystkie pliki yarn.lock w katalogu sources
  • */asset.json, !bin/**: wszystkie pliki asset.json znajdujące się w katalogu sources, oprócz tych w katalogu bin

Zawartość dowolnego pliku zidentyfikowanego przez ścieżkę pliku lub wzorzec pliku jest haszowana, aby utworzyć dynamiczny klucz pamięci podręcznej. Jest to przydatne, gdy projekt zawiera pliki, które jednoznacznie identyfikują, co jest buforowane. Na przykład pliki, takie jak package-lock.json, yarn.lock, Gemfile.locklub Pipfile.lock, są często przywołyne w kluczu pamięci podręcznej, ponieważ wszystkie reprezentują unikatowy zestaw zależności.

Względne ścieżki plików lub wzorce plików są rozwiązywane względem $(System.DefaultWorkingDirectory).

Przykład:

Oto przykład pokazujący sposób buforowania zależności zainstalowanych przez usługę Yarn:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/s/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       "yarn" | "$(Agent.OS)"
       "yarn"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

W tym przykładzie klucz pamięci podręcznej zawiera trzy części: ciąg statyczny ("yarn"), system operacyjny, na którym działa zadanie, ponieważ pamięć podręczna jest unikalna dla każdego systemu operacyjnego, oraz skrót pliku yarn.lock, który jednoznacznie identyfikuje zestaw zależności w pamięci podręcznej.

W pierwszym uruchomieniu po dodaniu zadania etap pamięci podręcznej zgłosi "brak pamięci podręcznej", ponieważ pamięć podręczna zidentyfikowana przez ten klucz nie istnieje. Po wykonaniu ostatniego kroku pamięć podręczna z plików w $(Pipeline.Workspace)/s/.yarn zostanie utworzona i załadowana. W następnym uruchomieniu krok pamięci podręcznej zgłosi "trafienie pamięci podręcznej", a zawartość pamięci podręcznej zostanie pobrana i przywrócona.

Podczas korzystania z checkout: selfrepozytorium jest skopiowane do $(Pipeline.Workspace)/s, a folder .yarn zwykle znajduje się w samym repozytorium.

Przywracanie kluczy

restoreKeys można użyć, jeśli chcesz wykonać zapytanie względem wielu dokładnych kluczy lub prefiksów kluczy. Służy do sięgnięcia po inny klucz w przypadku, gdy key nie daje trafienia. Klucz przywracania wyszukuje klucz według prefiksu i w rezultacie zwraca najnowszy utworzony wpis pamięci podręcznej. Jest to przydatne, jeśli potok nie może odnaleźć dokładnego dopasowania, ale zamiast tego chce użyć częściowej pamięci podręcznej. Aby wstawić wiele kluczy przywracania, ogranicz je przy użyciu nowego wiersza, aby wskazać klucz przywracania (zobacz przykład, aby uzyskać więcej szczegółów). Kolejność, według której klucze przywracania będą wypróbowywane, będzie od góry do dołu.

Wymagane oprogramowanie na własnym agencie

Powyższe pliki wykonywalne muszą znajdować się w folderze wymienionym w zmiennej środowiskowej PATH. Należy pamiętać, że hostowani agenci mają dołączone oprogramowanie; dotyczy to tylko agentów zainstalowanych samodzielnie.

Przykład:

Oto przykład, jak używać kluczy przywracania w Yarn:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

W tym przykładzie zadanie pamięci podręcznej próbuje znaleźć, czy klucz istnieje w pamięci podręcznej. Jeśli klucz nie istnieje w pamięci podręcznej, spróbuje użyć pierwszego klucza przywracania yarn | $(Agent.OS). Próbuje wyszukać wszystkie klucze, które są dokładnie zgodne z tym kluczem lub ma ten klucz jako prefiks. Może wystąpić trafienie prefiksu, jeśli wystąpił inny segment skrótu yarn.lock. Jeśli na przykład następujący klucz yarn | $(Agent.OS) | old-yarn.lock znajdował się w pamięci podręcznej, w której old-yarn.lock przyniosły inny skrót niż yarn.lock, klucz przywracania przyniesie częściowe trafienie. Jeśli w pierwszym kluczu przywracania wystąpi błąd, użyje następnego klucza przywracania yarn, który spróbuje znaleźć dowolny klucz rozpoczynający się od yarn. Dla trafień prefiksowych wynik zwraca ostatnio utworzony klucz pamięci podręcznej.

Izolacja i zabezpieczenia pamięci podręcznej

W celu zapewnienia izolacji między pamięciami podręcznymi z różnych potoków i gałęzi, każda z nich należy do kontenera logicznego nazywanego zakresem. Zakresy tworzą granicę zabezpieczeń, która gwarantuje:

1. Zadanie z jednego łańcucha nie może uzyskać dostępu do pamięci podręcznych z innego łańcucha i
2. Zadanie budujące pull request ma dostęp do odczytu pamięci podręcznych dla gałęzi docelowej pull requestu (dla tego samego potoku), ale nie może zapisywać ani tworzyć pamięci podręcznych w zakresie gałęzi docelowej.

Gdy w trakcie procesu natrafimy na etap pamięci podręcznej, pamięć podręczna zidentyfikowana przez klucz jest żądana z serwera. Następnie serwer szuka pamięci podręcznej z tym kluczem z zakresów widocznych dla zadania i zwraca pamięć podręczną (jeśli jest dostępna). W przypadku zapisywania pamięci podręcznej (na końcu zadania) pamięć podręczna jest zapisywana w zakresie reprezentującym potok i gałąź. Zobacz poniżej, aby uzyskać więcej informacji.

Przebiegi ciągłej integracji (CI), ręczne i zaplanowane

Uruchomienia żądań ściągnięcia

Uruchomienia forków pull requestów

Klimatyzacja przy przywracaniu pamięci podręcznej

W niektórych scenariuszach pomyślne przywrócenie pamięci podręcznej powinno spowodować uruchomienie innego zestawu kroków. Na przykład krok, który instaluje zależności, można pominąć, jeśli pamięć podręczna została przywrócona. Jest to możliwe przy użyciu danych wejściowych zadania cacheHitVar. Ustawienie tego wejścia na nazwę zmiennej środowiskowej powoduje, że zmienna jest ustawiana na true po trafieniu pamięci podręcznej, na inexact po trafieniu przy użyciu klucza przywracania, a w przeciwnym razie jest ustawiana na false. Tę zmienną można następnie odwołać w warunku kroku oznaczonym jako lub z poziomu skryptu.

W poniższym przykładzie krok install-deps.sh jest pomijany po przywróceniu pamięci podręcznej:

steps:
- task: Cache@2
  inputs:
    key: mykey | mylockfile
    restoreKeys: mykey
    path: $(Pipeline.Workspace)/mycache
    cacheHitVar: CACHE_RESTORED

- script: install-deps.sh
  condition: ne(variables.CACHE_RESTORED, 'true')

- script: build.sh

Bundler

W przypadku projektów Ruby korzystających z Bundlera, zastąp zmienną środowiskową BUNDLE_PATH używaną przez Bundlera, aby ustawić ścieżkę , w której Bundler wyszukuje Gems.

Przykład:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    path: $(BUNDLE_PATH)
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems   

Ccache (C/C++)

Ccache to pamięć podręczna kompilatora języka C/C++. Aby użyć usługi Ccache w potoku, upewnij się, że Ccache jest zainstalowana i opcjonalnie dodana do PATH (zobacz tryby uruchamiania Ccache). Ustaw zmienną środowiskową CCACHE_DIR na ścieżkę znajdującą się w katalogu $(Pipeline.Workspace) i keszuj ten katalog.

Przykład:

variables:
  CCACHE_DIR: $(Pipeline.Workspace)/ccache

steps:
- bash: |
    sudo apt-get install ccache -y    
    echo "##vso[task.prependpath]/usr/lib/ccache"
  displayName: Install ccache and update PATH to use linked versions of gcc, cc, etc

- task: Cache@2
  displayName: Ccache caching
  inputs:
    key: 'ccache | "$(Agent.OS)" | $(Build.SourceVersion)'
    path: $(CCACHE_DIR)
    restoreKeys: | 
      ccache | "$(Agent.OS)"

Aby uzyskać więcej informacji, zobacz ustawienia konfiguracji usługi Ccache.

Obrazy Docker

Buforowanie obrazów Dockera znacznie skraca czas potrzebnego do uruchomienia potoku.

variables:
  repository: 'myDockerImage'
  dockerfilePath: '$(Build.SourcesDirectory)/app/Dockerfile'
  tag: '$(Build.BuildId)'

pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: Cache@2
    displayName: Cache task
    inputs:
      key: 'docker | "$(Agent.OS)" | cache'
      path: $(Pipeline.Workspace)/docker
      cacheHitVar: CACHE_RESTORED                #Variable to set to 'true' when the cache is restored
    
  - script: |
      docker load -i $(Pipeline.Workspace)/docker/cache.tar
    displayName: Docker restore
    condition: and(not(canceled()), eq(variables.CACHE_RESTORED, 'true'))

  - task: Docker@2
    displayName: 'Build Docker'
    inputs:
      command: 'build'
      repository: '$(repository)'
      dockerfile: '$(dockerfilePath)'
      tags: |
        '$(tag)'

  - script: |
      mkdir -p $(Pipeline.Workspace)/docker
      docker save -o $(Pipeline.Workspace)/docker/cache.tar $(repository):$(tag)
    displayName: Docker save
    condition: and(not(canceled()), not(failed()), ne(variables.CACHE_RESTORED, 'true'))

• klucz: (wymagane) - jednoznaczny identyfikator pamięci podręcznej.
• ścieżka: (wymagane) — ścieżka folderu lub pliku, który chcesz buforować.

Golang

W przypadku projektów Języka Golang można określić pakiety do pobrania w pliku go.mod. Jeśli zmienna GOCACHE nie została jeszcze ustawiona, ustaw ją na lokalizację, w której ma zostać pobrana pamięć podręczna.

Przykład:

variables:
  GO_CACHE_DIR: $(Pipeline.Workspace)/.cache/go-build/

steps:
- task: Cache@2
  inputs:
    key: 'go | "$(Agent.OS)" | go.mod'
    restoreKeys: | 
      go | "$(Agent.OS)"
    path: $(GO_CACHE_DIR)
  displayName: Cache GO packages

Gradle

Użycie wbudowanej obsługi buforowania narzędzia Gradle może mieć znaczący wpływ na czas kompilacji. Aby włączyć pamięć podręczną kompilacji, ustaw zmienną środowiskową GRADLE_USER_HOME na ścieżkę w $(Pipeline.Workspace) i uruchom kompilację przy użyciu --build-cache lub dodaj org.gradle.caching=true do pliku gradle.properties.

Przykład:

variables:
  GRADLE_USER_HOME: $(Pipeline.Workspace)/.gradle

steps:
- task: Cache@2
  inputs:
    key: 'gradle | "$(Agent.OS)" | **/build.gradle.kts' # Swap build.gradle.kts for build.gradle when using Groovy
    restoreKeys: |
      gradle | "$(Agent.OS)"
      gradle
    path: $(GRADLE_USER_HOME)
  displayName: Configure gradle caching

- task: Gradle@2
  inputs:
    gradleWrapperFile: 'gradlew'
    tasks: 'build'
    options: '--build-cache'
  displayName: Build

- script: |   
    # stop the Gradle daemon to ensure no files are left open (impacting the save cache operation later)
    ./gradlew --stop    
  displayName: Gradlew stop

• restoreKeys: klucze rezerwowe, jeśli klucz podstawowy zakończy się niepowodzeniem (opcjonalnie)

Maven

Narzędzie Maven ma repozytorium lokalne, w którym przechowuje pobrane i skompilowane artefakty. Aby włączyć, ustaw opcję maven.repo.local na ścieżkę w obszarze $(Pipeline.Workspace) i wyznacz ten folder do buforowania.

Przykład:

variables:
  MAVEN_CACHE_FOLDER: $(Pipeline.Workspace)/.m2/repository
  MAVEN_OPTS: '-Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)'

steps:
- task: Cache@2
  inputs:
    key: 'maven | "$(Agent.OS)" | **/pom.xml'
    restoreKeys: |
      maven | "$(Agent.OS)"
      maven
    path: $(MAVEN_CACHE_FOLDER)
  displayName: Cache Maven local repo

- script: mvn install -B -e

Jeśli używasz zadania Maven, pamiętaj o przekazaniu zmiennej MAVEN_OPTS, ponieważ w przeciwnym razie zostanie nadpisana.

- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    mavenOptions: '-Xmx3072m $(MAVEN_OPTS)'

.NET/NuGet

Jeśli używasz PackageReferences do zarządzania zależnościami NuGet bezpośrednio w pliku projektu i masz plik packages.lock.json, możesz włączyć buforowanie, ustawiając zmienną środowiskową NUGET_PACKAGES na ścieżkę w $(UserProfile) i buforując ten katalog. Aby uzyskać więcej informacji na temat blokowania zależności, zobacz referencję do pakietu w plikach projektu . Jeśli chcesz użyć wielu packages.lock.json, nadal możesz użyć poniższego przykładu bez wprowadzania żadnych zmian. Zawartość wszystkich plików packages.lock.json zostanie skrócona i jeśli jeden z plików zostanie zmieniony, zostanie wygenerowany nowy klucz pamięci podręcznej.

Przykład:

variables:
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

steps:
- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | $(Build.SourcesDirectory)/**/packages.lock.json'
    restoreKeys: |
       nuget | "$(Agent.OS)"
       nuget
    path: $(NUGET_PACKAGES)
  displayName: Cache NuGet packages

Takie podejście jest również prawidłowe w przypadku projektów platformy .NET Core, jeśli projekt używa packages.lock.json do blokowania wersji pakietów. Możesz to włączyć, ustawiając RestorePackagesWithLockFile na True w pliku Csproj lub używając następującego polecenia: dotnet restore --use-lock-file.

Node.js/npm

Istnieją różne sposoby włączania buforowania w projekcie Node.js, ale zalecanym sposobem jest buforowanie katalogu udostępnionej pamięci podręcznej npm. Ten katalog jest zarządzany przez narzędzie npm i zawiera buforowaną wersję wszystkich pobranych modułów. Podczas instalacji narzędzie npm najpierw sprawdza ten katalog (domyślnie) dla modułów, które mogą zmniejszyć lub wyeliminować wywołania sieciowe do publicznego rejestru npm lub rejestru prywatnego.

Ponieważ domyślna ścieżka do katalogu udostępnionej pamięci podręcznej npm jest nie taka sama na wszystkich platformach, zaleca się zastąpienie zmiennej środowiskowej npm_config_cache ścieżką w $(Pipeline.Workspace). To również zapewnia, że pamięć podręczna jest dostępna zarówno z zadań kontenerowych, jak i niekontenerowych.

Przykład:

variables:
  npm_config_cache: $(Pipeline.Workspace)/.npm

steps:
- task: Cache@2
  inputs:
    key: 'npm | "$(Agent.OS)" | package-lock.json'
    restoreKeys: |
       npm | "$(Agent.OS)"
    path: $(npm_config_cache)
  displayName: Cache npm

- script: npm ci

Jeśli projekt nie ma pliku package-lock.json, należy odwołać się do pliku package.json w danych wejściowych klucza pamięci podręcznej.

Node.js/Yarn

Podobnie jak w przypadku narzędzia npm, istnieją różne sposoby buforowania pakietów zainstalowanych za pomocą narzędzia Yarn. Zalecanym sposobem jest buforowanie folderu udostępnionej pamięci podręcznej Yarn . Ten katalog jest zarządzany przez usługę Yarn i zawiera buforowaną wersję wszystkich pobranych pakietów. Podczas instalacji usługa Yarn najpierw sprawdza ten katalog (domyślnie) dla modułów, co może zmniejszyć lub wyeliminować wywołania sieciowe do rejestrów publicznych lub prywatnych.

Przykład:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: 'yarn | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

Python/Anaconda

Skonfiguruj buforowanie potoku przy użyciu środowisk Anaconda:

Przykład

variables:
  CONDA_CACHE_DIR: /usr/share/miniconda/envs

# Add conda to system path
steps:
- script: echo "##vso[task.prependpath]$CONDA/bin"
  displayName: Add conda to PATH

- bash: |
    sudo chown -R $(whoami):$(id -ng) $(CONDA_CACHE_DIR)
  displayName: Fix CONDA_CACHE_DIR directory permissions

- task: Cache@2
  displayName: Use cached Anaconda environment
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA_CACHE_DIR)
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create Anaconda environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

• Windows

  - task: Cache@2
    displayName: Cache Anaconda
    inputs:
      key: 'conda | "$(Agent.OS)" | environment.yml'
      restoreKeys: | 
        python | "$(Agent.OS)"
        python
      path: $(CONDA)/envs
      cacheHitVar: CONDA_CACHE_RESTORED
  
  - script: conda env create --quiet --file environment.yml
    displayName: Create environment
    condition: eq(variables.CONDA_CACHE_RESTORED, 'false')
  

PHP/Composer

W przypadku projektów PHP korzystających z narzędzia Composer zastąp zmienną środowiskową COMPOSER_CACHE_DIR używaną przez composera.

Przykład:

variables:
  COMPOSER_CACHE_DIR: $(Pipeline.Workspace)/.composer

steps:
- task: Cache@2
  inputs:
    key: 'composer | "$(Agent.OS)" | composer.lock'
    restoreKeys: |
      composer | "$(Agent.OS)"
      composer
    path: $(COMPOSER_CACHE_DIR)
  displayName: Cache composer

- script: composer install

Znane problemy i opinie

Jeśli występują problemy z konfigurowaniem buforowania dla potoku, sprawdź listę otwartych problemów w repozytorium microsoft/azure-pipelines-tasks. Jeśli nie widzisz swojego problemu na liście, utwórz nowy i podaj niezbędne informacje o swoim scenariuszu.

Q&A

Czy mogę wyczyścić pamięć podręczną?

Wyczyszczenie pamięci podręcznej nie jest obecnie obsługiwane. Można jednak dodać literał ciągu (na przykład version2) do istniejącego klucza pamięci podręcznej, aby zmienić klucz w sposób, który pozwala uniknąć jakichkolwiek trafień w istniejących pamięciach podręcznych. Na przykład zmień następujący klucz pamięci podręcznej z tego:

key: 'yarn | "$(Agent.OS)" | yarn.lock'

Do tego:

key: 'version2 | yarn | "$(Agent.OS)" | yarn.lock'

.: Kiedy pamięć podręczna wygaśnie?

Pamięci podręczne wygasają po siedmiu dniach braku aktywności.

Kiedy pamięć podręczna zostanie przekazywana?

Po ostatnim kroku twojego potoku zostanie utworzona pamięć podręczna z twojej pamięci podręcznej path i przesłana. Aby uzyskać więcej informacji, zobacz przykład .

.: Czy istnieje limit rozmiaru pamięci podręcznej?

1: Nie ma wymuszonego limitu rozmiaru poszczególnych pamięci podręcznych ani całkowitego rozmiaru wszystkich pamięci podręcznych w organizacji.