Share via


Problemen oplossen wanneer u Azure Cosmos DB Java SDK v4 gebruikt met API voor NoSQL-accounts

VAN TOEPASSING OP: NoSQL

Belangrijk

In dit artikel vindt u informatie over probleemoplossing voor alleen Azure Cosmos DB Java SDK v4. Raadpleeg de releaseopmerkingen, maven-opslagplaats en prestatietips voor Azure Cosmos DB Java SDK v4 voor meer informatie. Als u momenteel een oudere versie dan v4 gebruikt, raadpleegt u de handleiding Migreren naar Azure Cosmos DB Java SDK v4 voor hulp bij het upgraden naar v4.

In dit artikel worden veelvoorkomende problemen, tijdelijke oplossingen, diagnostische stappen en hulpprogramma's beschreven wanneer u Azure Cosmos DB Java SDK v4 gebruikt met Azure Cosmos DB voor NoSQL-accounts. Azure Cosmos DB Java SDK v4 biedt logische weergave aan de clientzijde voor toegang tot Azure Cosmos DB for NoSQL. In dit artikel worden tools en benaderingen beschreven om u te helpen bij eventuele problemen.

Begin met deze lijst:

  • Bekijk de sectie Veelvoorkomende problemen en tijdelijke oplossingen in dit artikel.
  • Bekijk de Java SDK in de centrale opslagplaats van Azure Cosmos DB, die open source beschikbaar is op GitHub. Het bevat een sectie met problemen die actief wordt bewaakt. Controleer of er al een vergelijkbaar probleem met een tijdelijke oplossing is opgeslagen. Een handige tip is om problemen te filteren op de *cosmos:v4-item* tag.
  • Bekijk de prestatietips voor Azure Cosmos DB Java SDK v4 en volg de voorgestelde procedures.
  • Lees de rest van dit artikel als u geen oplossing hebt gevonden. Dien vervolgens een GitHub-probleem in. Als er een optie is om tags toe te voegen aan uw GitHub-probleem, voegt u een *cosmos:v4-item* tag toe.

De diagnostische gegevens vastleggen

Database-, container-, item- en queryreacties in de Java V4 SDK hebben de eigenschap Diagnostiek. Deze eigenschap registreert alle informatie met betrekking tot de enkele aanvraag, inclusief of er nieuwe pogingen of tijdelijke fouten zijn opgetreden.

De diagnostische gegevens worden geretourneerd als een tekenreeks. De tekenreeks verandert met elke versie, omdat deze wordt verbeterd om verschillende scenario's beter op te lossen. Bij elke versie van de SDK kan de tekenreeks de indeling verbreken. Parseert de tekenreeks niet om wijzigingen die fouten veroorzaken te voorkomen.

In het volgende codevoorbeeld ziet u hoe u diagnostische logboeken leest met behulp van de Java V4 SDK:

Belangrijk

We raden u aan de minimaal aanbevolen versie van de Java V4 SDK te valideren en ervoor te zorgen dat u deze versie of hoger gebruikt. U kunt hier de aanbevolen versie controleren.

Databasebewerkingen

CosmosDatabaseResponse databaseResponse = client.createDatabaseIfNotExists(databaseName);
CosmosDiagnostics diagnostics = databaseResponse.getDiagnostics();
logger.info("Create database diagnostics : {}", diagnostics); 

Containerbewerkingen

CosmosContainerResponse containerResponse = database.createContainerIfNotExists(containerProperties,
                  throughputProperties);
CosmosDiagnostics diagnostics = containerResponse.getDiagnostics();
logger.info("Create container diagnostics : {}", diagnostics);

Itembewerkingen

// Write Item
CosmosItemResponse<Family> item = container.createItem(family, new PartitionKey(family.getLastName()),
                    new CosmosItemRequestOptions());
        
CosmosDiagnostics diagnostics = item.getDiagnostics();
logger.info("Create item diagnostics : {}", diagnostics);
        
// Read Item
CosmosItemResponse<Family> familyCosmosItemResponse = container.readItem(documentId,
                    new PartitionKey(documentLastName), Family.class);
        
CosmosDiagnostics diagnostics = familyCosmosItemResponse.getDiagnostics();
logger.info("Read item diagnostics : {}", diagnostics);

Querybewerkingen

String sql = "SELECT * FROM c WHERE c.lastName = 'Witherspoon'";
        
CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(),
                    Family.class);
        
//  Add handler to capture diagnostics
filteredFamilies = filteredFamilies.handle(familyFeedResponse -> {
    logger.info("Query Item diagnostics through handle : {}", 
    familyFeedResponse.getCosmosDiagnostics());
});
        
//  Or capture diagnostics through iterableByPage() APIs.
filteredFamilies.iterableByPage().forEach(familyFeedResponse -> {
    logger.info("Query item diagnostics through iterableByPage : {}",
    familyFeedResponse.getCosmosDiagnostics());
});

Azure Cosmos DB-uitzonderingen

try {
  CosmosItemResponse<Family> familyCosmosItemResponse = container.readItem(documentId,
                    new PartitionKey(documentLastName), Family.class);
} catch (CosmosException ex) {
  CosmosDiagnostics diagnostics = ex.getDiagnostics();
  logger.error("Read item failure diagnostics : {}", diagnostics);
}

De diagnostische gegevens vastleggen

Java V4 SDK-versies v4.43.0 en hoger ondersteunen automatische logboekregistratie van Cosmos Diagnostics voor alle aanvragen of fouten als ze voldoen aan bepaalde criteria. Toepassingsontwikkelaars kunnen drempelwaarden definiëren voor latentie (voor puntbewerkingen (maken, lezen, vervangen, upsert, patch) of niet-puntbewerkingen (query, wijzigingenfeed, bulk en batch)), kosten en nettoladinggrootte aanvragen. Als de aanvragen deze gedefinieerde drempelwaarden overschrijden, worden de cosmos-diagnostische gegevens voor deze aanvragen automatisch verzonden.

Standaard registreert de Java v4 SDK deze diagnostische gegevens automatisch in een specifieke indeling. Dit kan echter worden gewijzigd door de interface te implementeren CosmosDiagnosticsHandler en uw eigen aangepaste diagnostische handler te bieden.

Deze CosmosDiagnosticsThresholds en CosmosDiagnosticsHandler kunnen vervolgens worden gebruikt in CosmosClientTelemetryConfig object, die moeten worden doorgegeven CosmosClientBuilder tijdens het maken van een synchronisatie of asynchrone client.

OPMERKING: Deze drempelwaarden voor diagnostische gegevens worden toegepast op verschillende typen diagnostische gegevens, waaronder logboekregistratie, tracering en clienttelemetrie.

In de volgende codevoorbeelden ziet u hoe u drempelwaarden voor diagnostische gegevens, aangepaste logboekregistratie voor diagnostische gegevens definieert en gebruikt via de configuratie van clienttelemetrie:

Aangepaste drempelwaarden voor diagnostische gegevens definiëren

//  Create diagnostics threshold
CosmosDiagnosticsThresholds cosmosDiagnosticsThresholds = new CosmosDiagnosticsThresholds();
//  These thresholds are for demo purposes
//  NOTE: Do not use the same thresholds for production
cosmosDiagnosticsThresholds.setPayloadSizeThreshold(100_00);
cosmosDiagnosticsThresholds.setPointOperationLatencyThreshold(Duration.ofSeconds(1));
cosmosDiagnosticsThresholds.setNonPointOperationLatencyThreshold(Duration.ofSeconds(5));
cosmosDiagnosticsThresholds.setRequestChargeThreshold(100f);

Aangepaste diagnostische handler definiëren

//  By default, DEFAULT_LOGGING_HANDLER can be used
CosmosDiagnosticsHandler cosmosDiagnosticsHandler = CosmosDiagnosticsHandler.DEFAULT_LOGGING_HANDLER;

//  App developers can also define their own diagnostics handler
cosmosDiagnosticsHandler = new CosmosDiagnosticsHandler() {
    @Override
    public void handleDiagnostics(CosmosDiagnosticsContext diagnosticsContext, Context traceContext) {
        logger.info("This is custom diagnostics handler: {}", diagnosticsContext.toJson());
    }
};

CosmosClientTelemetryConfig definiëren

//  Create Client Telemetry Config
CosmosClientTelemetryConfig cosmosClientTelemetryConfig =
    new CosmosClientTelemetryConfig();
cosmosClientTelemetryConfig.diagnosticsHandler(cosmosDiagnosticsHandler);
cosmosClientTelemetryConfig.diagnosticsThresholds(cosmosDiagnosticsThresholds);

//  Create sync client
CosmosClient client = new CosmosClientBuilder()
    .endpoint(AccountSettings.HOST)
    .key(AccountSettings.MASTER_KEY)
    .clientTelemetryConfig(cosmosClientTelemetryConfig)
    .buildClient();

Ontwerp voor opnieuw proberen

Raadpleeg onze handleiding voor het ontwerpen van flexibele toepassingen met Azure Cosmos DB SDK's voor hulp bij het ontwerpen van tolerante toepassingen en het leren van de semantiek voor opnieuw proberen van de SDK.

Veelvoorkomende problemen en tijdelijke oplossingen

De metrische gegevens van de portal controleren

Door de metrische gegevens van de portal te controleren, kunt u bepalen of het een probleem aan de clientzijde is of of er een probleem is met de service. Als de metrische gegevens bijvoorbeeld een hoge snelheidslimiet voor aanvragen (HTTP-statuscode 429) bevatten, wat betekent dat de aanvraag wordt beperkt, controleert u de sectie Aanvraagsnelheid te groot .

Netwerkproblemen, time-outfout bij lezen van Netty, lage doorvoer, hoge latentie

Algemene suggesties

Voor de beste prestaties:

  • Zorg ervoor dat de app wordt uitgevoerd in dezelfde regio als uw Azure Cosmos DB-account.
  • Controleer het CPU-gebruik op de host waarop de app wordt uitgevoerd. Als het CPU-gebruik 50 procent of meer is, voert u uw app uit op een host met een hogere configuratie. Of u kunt de belasting op meer computers distribueren.

Verbindingsbeperking

Verbindingsbeperking kan optreden vanwege een verbindingslimiet op een hostcomputer of azure SNAT-poortuitputting (PAT).

Verbindingslimiet op een hostcomputer

Sommige Linux-systemen, zoals Red Hat, hebben een bovengrens voor het totale aantal geopende bestanden. Sockets in Linux worden geïmplementeerd als bestanden, dus dit aantal beperkt ook het totale aantal verbindingen. Voer de volgende opdracht uit.

ulimit -a

Het aantal maximaal toegestane geopende bestanden, die worden geïdentificeerd als 'nofile', moet ten minste een dubbele grootte hebben voor uw verbindingsgroep. Zie de prestatietips voor Azure Cosmos DB Java SDK v4 voor meer informatie.

Poortuitputting van Azure SNAT (PAT)

Als uw app is geïmplementeerd op virtuele Azure-machines zonder een openbaar IP-adres, maken standaard Azure SNAT-poorten verbindingen met een eindpunt buiten uw VM. Het aantal verbindingen dat van de VM naar het Azure Cosmos DB-eindpunt is toegestaan, wordt beperkt door de Azure SNAT-configuratie.

Azure SNAT-poorten worden alleen gebruikt wanneer uw VIRTUELE machine een privé-IP-adres heeft en een proces van de VM probeert verbinding te maken met een openbaar IP-adres. Er zijn twee tijdelijke oplossingen om azure SNAT-beperking te voorkomen:

  • Voeg uw Azure Cosmos DB-service-eindpunt toe aan het subnet van uw virtuele Azure-machines-netwerk. Zie Azure Virtual Network-service-eindpunten voor meer informatie.

    Wanneer het service-eindpunt is ingeschakeld, worden de aanvragen niet meer verzonden vanaf een openbaar IP-adres naar Azure Cosmos DB. In plaats daarvan worden de identiteit van het virtuele netwerk en het subnet verzonden. Deze wijziging kan leiden tot een daling van de firewall als alleen openbare IP-adressen zijn toegestaan. Als u een firewall gebruikt en u het service-eindpunt inschakelt, voegt u een subnet toe aan de firewall met behulp van ACL's voor virtueel netwerk.

  • Wijs een openbaar IP-adres toe aan uw Azure-VM.

Kan de service niet bereiken - firewall

ConnectTimeoutException geeft aan dat de SDK de service niet kan bereiken. Er kan een fout optreden die vergelijkbaar is met het volgende wanneer u de directe modus gebruikt:

GoneException{error=null, resourceAddress='https://cdb-ms-prod-westus-fd4.documents.azure.com:14940/apps/e41242a5-2d71-5acb-2e00-5e5f744b12de/services/d8aa21a5-340b-21d4-b1a2-4a5333e7ed8a/partitions/ed028254-b613-4c2a-bf3c-14bd5eb64500/replicas/131298754052060051p//', statusCode=410, message=Message: The requested resource is no longer available at the server., getCauseInfo=[class: class io.netty.channel.ConnectTimeoutException, message: connection timed out: cdb-ms-prod-westus-fd4.documents.azure.com/101.13.12.5:14940]

Als er een firewall wordt uitgevoerd op uw app-computer, opent u poortbereik 10.000 tot 20.000, die worden gebruikt door de directe modus. Volg ook de verbindingslimiet op een hostcomputer.

UnknownHostException

UnknownHostException betekent dat het Java-framework de DNS-vermelding voor het Azure Cosmos DB-eindpunt op de betreffende computer niet kan oplossen. Controleer of de computer de DNS-vermelding kan omzetten of als u een aangepaste DNS-omzettingssoftware (zoals VPN of proxy of een aangepaste oplossing) hebt, controleert u of deze de juiste configuratie bevat voor het DNS-eindpunt dat de fout claimt, niet kan worden omgezet. Als de fout constant is, kunt u de DNS-omzetting van de computer controleren via een curl opdracht naar het eindpunt dat in de fout wordt beschreven.

HTTP-proxy

Als u een HTTP-proxy gebruikt, moet u ervoor zorgen dat deze het aantal verbindingen ondersteunt dat is geconfigureerd in de SDK ConnectionPolicy. Anders ondervindt u verbindingsproblemen.

Ongeldig coderingspatroon: Netty IO-thread blokkeren

De SDK maakt gebruik van de Netty IO-bibliotheek om te communiceren met Azure Cosmos DB. De SDK heeft een Async-API en maakt gebruik van niet-blokkerende IO-API's van Netty. Het IO-werk van de SDK wordt uitgevoerd op IO Netty-threads. Het aantal IO Netty-threads is geconfigureerd om hetzelfde te zijn als het aantal CPU-kernen van de app-machine.

De Netty IO-threads zijn bedoeld om alleen te worden gebruikt voor niet-blokkerende Netty IO-werkzaamheden. De SDK retourneert het API-aanroepresultaat op een van de Netty IO-threads naar de code van de app. Als de app een langdurige bewerking uitvoert nadat deze resultaten heeft ontvangen op de Netty-thread, beschikt de SDK mogelijk niet over voldoende IO-threads om het interne IO-werk uit te voeren. Dergelijke app-codering kan leiden tot lage doorvoer, hoge latentie en io.netty.handler.timeout.ReadTimeoutException storingen. De tijdelijke oplossing is om de thread over te schakelen wanneer u weet dat de bewerking tijd kost.

Bekijk bijvoorbeeld het volgende codefragment, waarmee items worden toegevoegd aan een container (kijk hier voor hulp bij het instellen van de database en container).) U kunt langdurig werken met meer dan een paar milliseconden in de Netty-thread. Zo ja, dan krijgt u uiteindelijk een status waarin geen Netty IO-thread aanwezig is om IO-werk te verwerken. Als gevolg hiervan krijgt u een ReadTimeoutException-fout.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API


//Bad code with read timeout exception

int requestTimeoutInSeconds = 10;

/* ... */

AtomicInteger failureCount = new AtomicInteger();
// Max number of concurrent item inserts is # CPU cores + 1
Flux<Family> familyPub =
        Flux.just(Families.getAndersenFamilyItem(), Families.getAndersenFamilyItem(), Families.getJohnsonFamilyItem());
familyPub.flatMap(family -> {
    return container.createItem(family);
}).flatMap(r -> {
    try {
        // Time-consuming work is, for example,
        // writing to a file, computationally heavy work, or just sleep.
        // Basically, it's anything that takes more than a few milliseconds.
        // Doing such operations on the IO Netty thread
        // without a proper scheduler will cause problems.
        // The subscriber will get a ReadTimeoutException failure.
        TimeUnit.SECONDS.sleep(2 * requestTimeoutInSeconds);
    } catch (Exception e) {
    }
    return Mono.empty();
}).doOnError(Exception.class, exception -> {
    failureCount.incrementAndGet();
}).blockLast();
assert(failureCount.get() > 0);

De tijdelijke oplossing is om de thread te wijzigen waarop u werk uitvoert dat tijd in beslag neemt. Definieer een singleton-exemplaar van de scheduler voor uw app.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

// Have a singleton instance of an executor and a scheduler.
ExecutorService ex  = Executors.newFixedThreadPool(30);
Scheduler customScheduler = Schedulers.fromExecutor(ex);

Mogelijk moet u werk doen dat bijvoorbeeld veel rekenkracht kost of I/O blokkeert. In dit geval schakelt u de thread over naar een werkrol die door uw customScheduler wordt geleverd met behulp van de .publishOn(customScheduler) API.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

container.createItem(family)
        .publishOn(customScheduler) // Switches the thread.
        .subscribe(
                // ...
        );

Met behulp van publishOn(customScheduler), laat u de Netty IO-thread los en schakelt u over naar uw eigen aangepaste thread die wordt geleverd door de aangepaste planner. Deze wijziging lost het probleem op. Je krijgt io.netty.handler.timeout.ReadTimeoutException geen storing meer.

Aanvraagsnelheid is te hoog

Deze fout is een fout aan de serverzijde. Dit geeft aan dat u de ingerichte doorvoer hebt verbruikt. Probeer het later opnieuw. Als u deze fout vaak krijgt, kunt u overwegen om de verzamelingsdoorvoer te verhogen.

  • Uitstel implementeren bij intervallen van getRetryAfterInMilliseconds

    Tijdens het testen van de prestaties moet u de belasting verhogen totdat een klein aantal aanvragen wordt beperkt. Als de beperking is beperkt, moet de clienttoepassing uitstel opgeven voor het door de server opgegeven interval voor opnieuw proberen. Het respecteren van de uitstel zorgt ervoor dat u minimale tijd besteedt aan het wachten tussen nieuwe pogingen.

Foutafhandeling van Java SDK-reactieve keten

Foutafhandeling van De Java SDK van Azure Cosmos DB is belangrijk als het gaat om toepassingslogica van de client. Er zijn verschillende mechanismen voor foutafhandeling die worden geleverd door reactorkernframework dat in verschillende scenario's kan worden gebruikt. We raden klanten aan om deze operators voor foutafhandeling in detail te begrijpen en de operators te gebruiken die het beste passen bij hun scenario's voor opnieuw proberen.

Belangrijk

Het wordt afgeraden om operator te gebruiken onErrorContinue() , omdat deze in alle scenario's niet wordt ondersteund. Houd er rekening mee dat onErrorContinue() dit een specialist is die het gedrag van uw reactieve keten onduidelijk kan maken. Het werkt op upstream- en niet downstreamoperators, er is specifieke operatorondersteuning vereist om te werken en het bereik kan eenvoudig upstream worden doorgegeven aan bibliotheekcode die deze niet had verwacht (wat resulteert in onbedoeld gedrag.). Raadpleeg de documentatie voor onErrorContinue() meer informatie over deze speciale operator.

Fout bij het maken van verbinding met Azure Cosmos DB Emulator

Het HTTPS-certificaat van Azure Cosmos DB Emulator is zelfondertekend. Voordat de SDK met de emulator werkt, importeert u het emulatorcertificaat in een Java TrustStore. Zie Azure Cosmos DB Emulator-certificaten exporteren voor meer informatie.

Problemen met afhankelijkheidsconflicten

De Azure Cosmos DB Java SDK haalt veel afhankelijkheden op; Over het algemeen kan het zijn dat als uw projectafhankelijkheidsstructuur een oudere versie van een artefact bevat waarvan Azure Cosmos DB Java SDK afhankelijk is, dit kan leiden tot onverwachte fouten die worden gegenereerd wanneer u uw toepassing uitvoert. Als u fouten opspoort waarom uw toepassing onverwacht een uitzondering genereert, is het een goed idee om te controleren of uw afhankelijkheidsstructuur niet per ongeluk een oudere versie van een of meer Azure Cosmos DB Java SDK-afhankelijkheden ophaalt.

De tijdelijke oplossing voor een dergelijk probleem is om te bepalen welke van uw projectafhankelijkheden de oude versie bevat en de transitieve afhankelijkheid van die oudere versie uitsluit, en azure Cosmos DB Java SDK de nieuwere versie kan geven.

Voer de volgende opdracht uit voor uw project pom.xml-bestand om te bepalen op welke van uw projectafhankelijkheden een oudere versie van iets is waarvan azure Cosmos DB Java SDK afhankelijk is:

mvn dependency:tree

Zie de handleiding voor de maven-afhankelijkheidsstructuur voor meer informatie.

Zodra u weet welke afhankelijkheid van uw project afhankelijk is van een oudere versie, kunt u de afhankelijkheid van die lib in uw pom-bestand wijzigen en de transitieve afhankelijkheid uitsluiten, volgens het onderstaande voorbeeld (waarbij wordt ervan uitgegaan dat reactor-core de verouderde afhankelijkheid is):

<dependency>
  <groupId>${groupid-of-lib-which-brings-in-reactor}</groupId>
  <artifactId>${artifactId-of-lib-which-brings-in-reactor}</artifactId>
  <version>${version-of-lib-which-brings-in-reactor}</version>
  <exclusions>
    <exclusion>
      <groupId>io.projectreactor</groupId>
      <artifactId>reactor-core</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Zie de gids voor transitieve afhankelijkheid uitsluiten voor meer informatie.

Logboekregistratie van client-SDK inschakelen

Azure Cosmos DB Java SDK v4 maakt gebruik van SLF4j als de façade voor logboekregistratie die ondersteuning biedt voor logboekregistratie in populaire frameworks voor logboekregistratie, zoals log4j en logback.

Als u bijvoorbeeld log4j wilt gebruiken als logboekregistratieframework, voegt u de volgende bibliotheken toe in uw Java-klassepad.

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>${slf4j.version}</version>
</dependency>
<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>${log4j.version}</version>
</dependency>

Voeg ook een log4j-configuratie toe.

# this is a sample log4j configuration

# Set root logger level to INFO and its only appender to A1.
log4j.rootLogger=INFO, A1

log4j.category.com.azure.cosmos=INFO
#log4j.category.io.netty=OFF
#log4j.category.io.projectreactor=OFF
# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d %5X{pid} [%t] %-5p %c - %m%n

Zie de handleiding voor logboekregistratie van sfl4j voor meer informatie.

Statistieken van het besturingssysteemnetwerk

Voer de netstat-opdracht uit om een idee te krijgen van het aantal verbindingen in statussen zoals ESTABLISHED en CLOSE_WAIT.

In Linux kunt u de volgende opdracht uitvoeren.

netstat -nap

In Windows kunt u dezelfde opdracht uitvoeren met verschillende argumentvlagmen:

netstat -abn

Filter het resultaat op alleen verbindingen met het Azure Cosmos DB-eindpunt.

Het aantal verbindingen met het Azure Cosmos DB-eindpunt in de status kan niet groter zijn dan de ESTABLISHED grootte van de geconfigureerde verbindingsgroep.

Veel verbindingen met het Azure Cosmos DB-eindpunt hebben mogelijk de CLOSE_WAIT status. Er kunnen meer dan 1.000 zijn. Een getal dat hoog aangeeft dat verbindingen tot stand zijn gebracht en snel worden uitgesplitst. Deze situatie veroorzaakt mogelijk problemen. Zie de sectie Veelvoorkomende problemen en tijdelijke oplossingen voor meer informatie.

Veelvoorkomende queryproblemen

De metrische querygegevens helpen bepalen waar de query het grootste deel van de tijd doorbrengt. In de metrische querygegevens kunt u zien hoeveel er wordt besteed aan de back-end versus de client. Meer informatie over de handleiding voor queryprestaties.

Volgende stappen

  • Meer informatie over prestatierichtlijnen voor de Java SDK v4
  • Meer informatie over de aanbevolen procedures voor de Java SDK v4