Share via

Prestatieproblemen met Azure Files oplossen

  • Artikel

Opmerking

CentOS waarnaar in dit artikel wordt verwezen, is een Linux-distributie en bereikt end of life (EOL). Overweeg uw gebruik en plan dienovereenkomstig. Zie Richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Dit artikel bevat veelvoorkomende problemen met betrekking tot de prestaties van Azure-bestandsshares en biedt mogelijke oorzaken en tijdelijke oplossingen. Als u het meeste uit deze probleemoplossingsgids wilt halen, raden we u aan eerst Inzicht in Azure Files prestaties te lezen.

Van toepassing op

Type bestandsshare SMB NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaard bestandsshares (GPv2), GRS/GZRS
Premium-bestandsshares (FileStorage), LRS/ZRS

Algemene prestatieproblemen oplossen

Sluit eerst enkele veelvoorkomende redenen uit waarom u prestatieproblemen ondervindt.

U gebruikt een oud besturingssysteem

Als op uw virtuele clientmachine (VM) Windows 8.1 of Windows Server 2012 R2 of een oudere Linux-distributie of -kernel wordt uitgevoerd, kunnen prestatieproblemen optreden bij het openen van Azure-bestandsshares. Werk uw clientbesturingssystemen bij of pas de onderstaande oplossingen toe.

Overwegingen voor Windows 8.1 en Windows Server 2012 R2

Clients met Windows 8.1 of Windows Server 2012 R2 zien mogelijk een hogere latentie dan verwacht bij het openen van Azure-bestandsshares voor I/O-intensieve workloads. Zorg ervoor dat de hotfix voor KB3114025 is geïnstalleerd. Deze hotfix verbetert de prestaties van het maken en sluiten van grepen.

U kunt het volgende script uitvoeren om te controleren of de hotfix is geïnstalleerd:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

Als de hotfix is geïnstalleerd, wordt de volgende uitvoer weergegeven:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

Opmerking

Windows Server 2012 R2-installatiekopieën in Azure Marketplace vanaf december 2015 standaard hotfix-KB3114025 geïnstalleerd.

Uw workload wordt beperkt

Aanvragen worden beperkt wanneer de I/O-bewerkingen per seconde (IOPS), inkomend verkeer of uitgaande limieten voor een bestandsshare zijn bereikt. Als de client bijvoorbeeld de IOPS van de basislijn overschrijdt, wordt deze beperkt door de Azure Files-service. Beperking kan ertoe leiden dat de client slechte prestaties ondervindt.

Zie Doelen voor bestandsshares en bestandsschaal voor meer informatie over de limieten voor Standard - en Premium-bestandsshares. Afhankelijk van uw workload kan beperking vaak worden vermeden door over te stappen van standard naar premium Azure-bestandsshares.

Zie Share- of opslagaccount wordt beperkt voor meer informatie over hoe beperking op share- of opslagaccountniveau kan leiden tot hoge latentie, lage doorvoer en algemene prestatieproblemen.

Hoge latentie, lage doorvoer of lage IOPS

Oorzaak 1: Het share- of opslagaccount wordt beperkt

Als u wilt controleren of uw share- of opslagaccount wordt beperkt, kunt u metrische gegevens van Azure openen en gebruiken in de portal. U kunt ook waarschuwingen maken die u op de hoogte stellen als een share wordt beperkt of op het punt staat te worden beperkt. Zie Problemen met Azure Files oplossen door waarschuwingen te maken.

Belangrijk

Voor standaardopslagaccounts waarvoor grote bestandsshares (LFS) zijn ingeschakeld, treedt beperking op op accountniveau. Voor Premium-bestandsshares en standaardbestandsshares zonder LFS ingeschakeld, treedt beperking op op shareniveau.

  1. Ga in de Azure Portal naar uw opslagaccount.

  2. Selecteer in het linkerdeelvenster onder Bewakingde optie Metrische gegevens.

  3. Selecteer Bestand als de metrische naamruimte voor het bereik van uw opslagaccount.

  4. Selecteer Transacties als metrische waarde.

  5. Voeg een filter toe voor antwoordtype en controleer vervolgens of er aanvragen zijn beperkt.

    Voor standaardbestandsshares waarvoor geen grote bestandsshares zijn ingeschakeld, worden de volgende antwoordtypen geregistreerd als een aanvraag wordt beperkt op shareniveau:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    Voor standaardbestandsshares waarvoor grote bestandsshares zijn ingeschakeld, worden de volgende antwoordtypen geregistreerd als een aanvraag wordt beperkt op clientaccountniveau:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Voor Premium-bestandsshares worden de volgende antwoordtypen geregistreerd als een aanvraag wordt beperkt op shareniveau:

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareEgressThrottlingError
    • ClientShareIngressThrottlingError
    • ClientShareIopsThrottlingError

    Als een beperkte aanvraag is geverifieerd met Kerberos, ziet u mogelijk een voorvoegsel dat het verificatieprotocol aangeeft, zoals:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Zie Metrische dimensies voor meer informatie over elk antwoordtype.

    Schermopname van het eigenschapsfilter 'Antwoordtype'.

Oplossing

Oorzaak 2: Workload voor metagegevens of naamruimten

Als de meeste aanvragen op metagegevens zijn gericht (zoals createfile, openfile, closefile, queryinfoof querydirectory), is de latentie slechter dan die van lees-/schrijfbewerkingen.

Als u wilt bepalen of de meeste aanvragen op metagegevens zijn gericht, begint u met de stappen 1-4, zoals eerder beschreven in Oorzaak 1. Voor stap 5 voegt u in plaats van een filter voor antwoordtype een eigenschappenfilter toe voor API-naam.

Schermopname van het eigenschapsfilter 'API-naam'.

Oplossingen

  • Controleer of de toepassing kan worden gewijzigd om het aantal metagegevensbewerkingen te verminderen.

  • Als u premium SMB Azure-bestandsshares gebruikt, gebruikt u metagegevens in cache opslaan.

  • Scheid de bestandsshare op in meerdere bestandsshares binnen hetzelfde opslagaccount.

  • Voeg een virtuele harde schijf (VHD) toe aan de bestandsshare en koppel de VHD vanaf de client om bestandsbewerkingen op de gegevens uit te voeren. Deze benadering werkt voor scenario's met één schrijver/lezer of scenario's met meerdere lezers en zonder schrijvers. Omdat het bestandssysteem eigendom is van de client in plaats van Azure Files, kunnen metagegevensbewerkingen lokaal zijn. De installatie biedt prestaties die vergelijkbaar zijn met die van lokaal rechtstreeks gekoppelde opslag. Omdat de gegevens zich echter in een VHD bevinden, zijn ze niet toegankelijk via een andere manier dan de SMB-koppeling, zoals REST API of via de Azure Portal.

    1. Koppel de bestandsshare vanaf de computer die toegang moet hebben tot de Azure-bestandsshare met behulp van de sleutel van het opslagaccount en wijs deze toe aan een beschikbaar netwerkstation (bijvoorbeeld Z:).
    2. Ga naar Schijfbeheer en selecteer Actie > Creatie VHD.
    3. Stel Locatie in op het netwerkstation waaraan de Azure-bestandsshare is toegewezen, stel indien nodig de grootte van de virtuele harde schijf in en selecteer Vaste grootte.
    4. Selecteer OK. Zodra het maken van de VHD is voltooid, wordt deze automatisch gekoppeld en wordt er een nieuwe niet-toegewezen schijf weergegeven.
    5. Klik met de rechtermuisknop op de nieuwe onbekende schijf en selecteer Schijf initialiseren.
    6. Klik met de rechtermuisknop op het niet-toegewezen gebied en maak een nieuw eenvoudig volume.
    7. Er wordt een nieuwe stationsletter weergegeven in Schijfbeheer die deze VHD vertegenwoordigt met lees-/schrijftoegang (bijvoorbeeld E:). In Bestandenverkenner ziet u de nieuwe VHD op het netwerkstation van de toegewezen Azure-bestandsshare (Z: in dit voorbeeld). Voor alle duidelijkheid, er moeten twee stationsletters aanwezig zijn: de standaard Azure-bestandssharenetwerktoewijzing op Z: en de VHD-toewijzing op het E:-station.
    8. Er zouden veel betere prestaties moeten zijn voor zware metagegevensbewerkingen voor bestanden op het toegewezen VHD-station (E:) in vergelijking met het toegewezen azure-station (Z:). Indien gewenst moet het mogelijk zijn om het toegewezen netwerkstation (Z:) los te koppelen en toch toegang te krijgen tot het gekoppelde VHD-station (E:).
    • Als u een VHD wilt koppelen aan een Windows-client, kunt u ook de Mount-DiskImage PowerShell-cmdlet gebruiken.
    • Als u een VHD op Linux wilt koppelen, raadpleegt u de documentatie voor uw Linux-distributie. Hier volgt een voorbeeld.

Oorzaak 3: Toepassing met één thread

Als de toepassing die u gebruikt één thread heeft, kan deze instelling resulteren in een aanzienlijk lagere IOPS-doorvoer dan de maximaal mogelijke doorvoer, afhankelijk van de grootte van uw ingerichte share.

Oplossing

  • Verhoog toepassingsparallellisme door het aantal threads te verhogen.
  • Schakel over naar toepassingen waar parallellisme mogelijk is. Voor kopieerbewerkingen kunt u bijvoorbeeld AzCopy of RoboCopy van Windows-clients of de parallelle opdracht van Linux-clients gebruiken.

Oorzaak 4: het aantal SMB-kanalen overschrijdt vier

Als u SMB MultiChannel gebruikt en het aantal kanalen dat u hebt groter is dan vier, resulteert dit in slechte prestaties. Als u wilt bepalen of het aantal verbindingen groter is dan vier, gebruikt u de PowerShell-cmdlet get-SmbClientConfiguration om de huidige instellingen voor het aantal verbindingen weer te geven.

Oplossing

Stel de instelling Windows per NIC in voor SMB, zodat het totaal aantal kanalen niet groter is dan vier. Als u bijvoorbeeld twee NIC's hebt, kunt u het maximum per NIC instellen op twee met behulp van de volgende PowerShell-cmdlet: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Oorzaak 5: Lees vooruit lezen is te klein (alleen NFS)

Vanaf Linux-kernelversie 5.4 gebruikt de Linux NFS-client een standaardwaarde read_ahead_kb van 128 kibibytes (KiB). Deze kleine waarde kan de hoeveelheid leesdoorvoer voor grote bestanden verminderen.

Oplossing

U wordt aangeraden de waarde van de read_ahead_kb kernelparameter te verhogen tot 15 mebibytes (MiB). Als u deze waarde wilt wijzigen, stelt u de grootte van read-ahead permanent in door een regel toe te voegen in udev, een Linux-kernelapparaatbeheer. Volg deze stappen:

  1. Maak in een teksteditor het bestand /etc/udev/rules.d/99-nfs.rules door de volgende tekst in te voeren en op te slaan:

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. Pas in een console de udev-regel toe door de opdracht udevadm uit te voeren als supergebruiker en de regelbestanden en andere databases opnieuw te laden. Als u udev op de hoogte wilt stellen van het nieuwe bestand, hoeft u deze opdracht maar één keer uit te voeren.

    sudo udevadm control --reload

Zeer hoge latentie voor aanvragen

Oorzaak

De client-VM bevindt zich mogelijk in een andere regio dan de bestandsshare. Een andere reden voor hoge latentie kan worden veroorzaakt door de latentie die wordt veroorzaakt door de client of het netwerk.

Oplossing

  • Voer de toepassing uit vanaf een VM die zich in dezelfde regio bevindt als de bestandsshare.
  • Bekijk voor uw opslagaccount de metrische transactiegegevens SuccessE2ELatency en SuccessServerLatency via Azure Monitor in Azure Portal. Een groot verschil tussen metrische waarden voor SuccessE2ELatency en SuccessServerLatency is een indicatie van latentie die waarschijnlijk wordt veroorzaakt door het netwerk of de client. Zie Metrische transactiegegevens in Azure Files Naslaginformatie over bewakingsgegevens.

Client kan geen maximale doorvoer bereiken die wordt ondersteund door het netwerk

Oorzaak

Een mogelijke oorzaak is een gebrek aan SMB-ondersteuning voor meerdere kanalen voor standaardbestandsshares. Momenteel ondersteunt Azure Files slechts één kanaal voor standaardbestandsshares, dus er is slechts één verbinding tussen de client-VM en de server. Deze enkele verbinding is gekoppeld aan één kern op de client-VM, zodat de maximale doorvoer die vanuit een VM kan worden gerealiseerd, wordt gebonden door één kern.

Tijdelijke oplossing

Trage prestaties op een Azure-bestandsshare die is gekoppeld aan een Linux-VM

Oorzaak 1: Caching

Een mogelijke oorzaak van trage prestaties is uitgeschakelde cache. Caching kan handig zijn als u herhaaldelijk toegang hebt tot een bestand. Anders kan het een overhead zijn. Controleer of u de cache gebruikt voordat u deze uitschakelt.

Oplossing voor oorzaak 1

Als u wilt controleren of caching is uitgeschakeld, zoekt u naar de cache= vermelding.

Cache=none geeft aan dat caching is uitgeschakeld. Koppel de share opnieuw met behulp van de standaardkoppelingsopdracht of door de cache=strict optie expliciet toe te voegen aan de koppelingsopdracht om ervoor te zorgen dat de standaardcachingmodus of de 'strikte' cachemodus is ingeschakeld.

In sommige scenario's kan de koppelingsoptie serverino ervoor zorgen dat de ls opdracht wordt uitgevoerd stat voor elke directory-vermelding. Dit gedrag leidt tot prestatievermindering wanneer u een grote map weergeeft. U kunt de koppelingsopties in uw /etc/fstab-vermelding controleren:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

U kunt ook controleren of de juiste opties worden gebruikt door de opdracht uit te voeren en de sudo mount | grep cifs uitvoer ervan te controleren. Hier volgt een voorbeelduitvoer:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Als de cache=strict optie of serverino niet aanwezig is, ontkoppelt en koppelt u Azure Files opnieuw door de koppelingsopdracht uit de documentatie uit te voeren. Controleer vervolgens opnieuw of de vermelding /etc/fstab de juiste opties heeft.

Oorzaak 2: beperking

Het is mogelijk dat u last hebt van beperking en dat uw aanvragen naar een wachtrij worden verzonden. U kunt dit controleren door gebruik te maken van metrische gegevens van Azure Storage in Azure Monitor. U kunt ook waarschuwingen maken die u waarschuwen als een share wordt beperkt of op het punt staat te worden beperkt. Zie Problemen met Azure Files oplossen door waarschuwingen te maken.

Oplossing voor oorzaak 2

Zorg ervoor dat uw app binnen de Azure Files schaaldoelen valt. Als u standaard Azure-bestandsshares gebruikt, kunt u overwegen over te schakelen naar Premium.

De doorvoer op Linux-clients is lager dan die van Windows-clients

Oorzaak

Dit is een bekend probleem met het implementeren van de SMB-client in Linux.

Tijdelijke oplossing

  • De belasting verdelen over meerdere VM's.
  • Gebruik op dezelfde VM meerdere koppelpunten met een nosharesock optie en verspreid de belasting over deze koppelpunten.
  • Probeer in Linux te koppelen met een nostrictsync optie om te voorkomen dat bij elke fsync aanroep een SMB-flush wordt afgedwongen. Voor Azure Files heeft deze optie geen invloed op gegevensconsistentie, maar kan dit leiden tot verouderde metagegevens van bestanden in mapvermeldingen (ls -lopdracht). Als u rechtstreeks een query uitvoert op metagegevens van bestanden met behulp van de stat opdracht, worden de meest recente metagegevens van het bestand geretourneerd.

Hoge latentie voor werkbelastingen met veel metagegevens, waarbij uitgebreide open/close-bewerkingen zijn betrokken

Oorzaak

Geen ondersteuning voor directory-leases.

Tijdelijke oplossing

  • Vermijd, indien mogelijk, het gebruik van een te grote greep voor openen/sluiten in dezelfde map binnen een korte periode.
  • Voor Linux-VM's verhoogt u de time-out van de mapvermeldingscache door op te geven als koppelingsoptie actimeo=<sec> . De time-out is standaard 1 seconde, dus een grotere waarde, zoals 30 seconden, kan helpen.
  • Voor CENTOS Linux- of RhEL-VM's (Red Hat Enterprise Linux) voert u een upgrade uit naar CentOS Linux 8.2 of RHEL 8.2. Voor andere Linux-distributies upgradet u de kernel naar 5.0 of hoger.

Trage inventarisatie van bestanden en mappen

Oorzaak

Dit probleem kan optreden als er onvoldoende cache op de clientcomputer is voor grote mappen.

Oplossing

U kunt dit probleem oplossen door de DirectoryCacheEntrySizeMax registerwaarde aan te passen zodat grotere directory-vermeldingen op de clientcomputer in de cache kunnen worden opgeslagen:

  • Locatie: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Waardenaam: DirectoryCacheEntrySizeMax
  • Waardetype: DWORD

U kunt deze bijvoorbeeld instellen op 0x100000 en zien of de prestaties verbeteren.

Langzaam kopiëren van bestanden naar en van Azure-bestandsshares

Mogelijk ziet u trage prestaties wanneer u bestanden probeert over te brengen naar de Azure Files-service. Als u geen specifieke minimale I/O-grootte hebt, raden we u aan 1 MiB als I/O-grootte te gebruiken voor optimale prestaties.

Langzaam kopiëren van bestanden naar en van Azure Files in Windows

  • Als u de uiteindelijke grootte van een bestand weet dat u uitbreidt met schrijfbewerkingen en uw software geen compatibiliteitsproblemen heeft wanneer de ongeschreven staart van het bestand nullen bevat, stelt u de bestandsgrootte vooraf in, in plaats van elke schrijfbewerking een uitgebreide schrijfbewerking te maken.

  • Gebruik de juiste kopieermethode:

    • Gebruik AzCopy voor elke overdracht tussen twee bestandsshares.
    • Gebruik Robocopy tussen bestandsshares op een on-premises computer.

Overmatige DirectoryOpen/DirectoryClose-aanroepen

Oorzaak

Als het aantal DirectoryOpen/DirectoryClose-aanroepen tot de belangrijkste API-aanroepen behoort en u niet verwacht dat de client zoveel aanroepen zal uitvoeren, kan het probleem worden veroorzaakt door de antivirussoftware die is geïnstalleerd op de Azure-client-VM.

Tijdelijke oplossing

Een oplossing voor dit probleem is beschikbaar in de platformupdate van april voor Windows.

SMB Meerdere kanalen wordt niet geactiveerd

Oorzaak

Recente wijzigingen in configuratie-instellingen voor SMB-meerdere kanalen zonder opnieuw te koppelen.

Oplossing

  • Nadat u wijzigingen hebt aangebracht in de configuratie-instellingen van de Windows SMB-client of het SMB-account met meerdere kanalen, moet u de share ontkoppelen, 60 seconden wachten en de share opnieuw koppelen om de meerkanaals te activeren.
  • Voor het Windows-clientbesturingssysteem genereert u io-belasting met een hoge wachtrijdiepte, bijvoorbeeld QD=8, bijvoorbeeld door een bestand te kopiëren om SMB Multichannel te activeren. Voor het besturingssysteem van de server wordt SMB Multichannel geactiveerd met QD=1, wat betekent dat zodra u een I/O naar de share start.

Trage prestaties bij het uitpakken van bestanden

Afhankelijk van de exacte compressiemethode en uitpakbewerking die wordt gebruikt, kunnen decompressiebewerkingen langzamer worden uitgevoerd op een Azure-bestandsshare dan op uw lokale schijf. Dit komt vaak doordat hulpprogramma's voor uitpakken een aantal metagegevensbewerkingen uitvoeren tijdens het uitvoeren van de decompressie van een gecomprimeerd archief. Voor de beste prestaties raden we u aan het gecomprimeerde archief van de Azure-bestandsshare naar uw lokale schijf te kopiëren, daar uit te schakelen en vervolgens een kopieerprogramma zoals Robocopy (of AzCopy) te gebruiken om terug te kopiëren naar de Azure-bestandsshare. Het gebruik van een kopieerprogramma zoals Robocopy kan de verminderde prestaties van metagegevensbewerkingen in Azure Files ten opzichte van uw lokale schijf compenseren door meerdere threads te gebruiken om gegevens parallel te kopiëren.

Hoge latentie op websites die worden gehost op bestandsshares

Oorzaak

Melding voor het wijzigen van een hoog aantal bestanden op bestandsshares kan leiden tot hoge latenties. Dit gebeurt meestal bij websites die worden gehost op bestandsshares met een diep geneste mapstructuur. Een typisch scenario is een door IIS gehoste webtoepassing waarbij een melding voor bestandswijzigingen wordt ingesteld voor elke map in de standaardconfiguratie. Elke wijziging (ReadDirectoryChangesW) op de share waarvoor de client is geregistreerd, pusht een wijzigingsmelding van de bestandsservice naar de client, die systeembronnen in beslag neemt, en het probleem verergert met het aantal wijzigingen. Dit kan leiden tot share-beperking en dus tot een hogere latentie aan de clientzijde.

Ter bevestiging kunt u Metrische gegevens van Azure gebruiken in de portal.

  1. Ga in de Azure Portal naar uw opslagaccount.
  2. Selecteer in het linkermenu onder Bewaking de optie Metrische gegevens.
  3. Selecteer Bestand als de metrische naamruimte voor het bereik van uw opslagaccount.
  4. Selecteer Transacties als metrische waarde.
  5. Voeg een filter toe voor ResponseType en controleer of aanvragen een antwoordcode hebben van SuccessWithThrottling (voor SMB of NFS) of ClientThrottlingError (voor REST).

Oplossing

  • Als de melding voor bestandswijziging niet wordt gebruikt, schakelt u de melding voor bestandswijzigingen uit (bij voorkeur).

  • Verhoog de frequentie van het pollinginterval voor bestandswijzigingen om het volume te verminderen.

    Werk het polling-interval voor het W3WP-werkproces bij naar een hogere waarde (bijvoorbeeld 10 of 30 minuten) op basis van uw behoeften. Stel HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSecondsin het register in en start het W3WP-proces opnieuw.

  • Als de toegewezen fysieke map van uw website een geneste mapstructuur heeft, kunt u proberen het bereik van meldingen voor bestandswijzigingen te beperken om het meldingsvolume te verminderen. STANDAARD maakt IIS gebruik van configuratie van Web.config bestanden in de fysieke map waaraan de virtuele map is toegewezen, evenals in onderliggende mappen in die fysieke map. Als u geenWeb.config bestanden in onderliggende mappen wilt gebruiken, geeft u false op voor het allowSubDirConfig kenmerk in de virtuele map. Meer informatie vindt u hier.

    Stel de instelling voor virtuele IIS-mappen allowSubDirConfig in Web.Config in op false om toegewezen fysieke onderliggende mappen van het bereik uit te sluiten.

Zie ook

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.