Le migliori pratiche prestazionali per AWS SDK per .NET

Il modo in cui create i client, gestite le risposte e configurate l'applicazione ha un grande effetto sulla velocità effettiva, sulla latenza e sull'uso della memoria. Questo argomento descrive i modelli di utilizzo e configurazione che aiutano le applicazioni a funzionare in modo efficiente e affidabile. Questi modelli sono particolarmente importanti in condizioni di carico elevato o in ambienti con risorse limitate, come contenitori e funzioni serverless. Seguendo queste pratiche è possibile migliorare le prestazioni e prevenire problemi comuni come risposte lente, blocchi e uso elevato della memoria.

Le pratiche più efficaci sono le seguenti:

Prima di iniziare, assicurati di aver impostato il tuo ambiente e configurato il tuo progetto.

Riutilizza un singolo client di servizio di lunga durata

I client di servizio come AmazonS3Client AmazonDynamoDBClient sono thread-safe, relativamente costosi da costruire e duraturi. La creazione di un client risolve le informazioni sulla regione e sugli endpoint e stabilisce l'infrastruttura HTTP sottostante. Crea un client per servizio e riutilizzalo per tutta la durata dell'applicazione. Se chiami più di una regione, crea un client separato per ciascuna regione.

Nelle applicazioni che utilizzano l'iniezione di dipendenze, registrate il client come singleton. Il metodo di AddAWSService estensione del AWSSDK.Extensions.NETCore.Setup NuGet pacchetto registra il client con una durata predefinita di. ServiceLifetime.Singleton Il client viene creato la prima volta che viene richiesto e la stessa istanza viene riutilizzata per tutta la durata del processo. Per ulteriori informazioni sulla registrazione AWS dei servizi con inserimento delle dipendenze e sulle opzioni di lettura della configurazione, vedere. AWSSDK.Extensions.NETCore.Setup e iConfiguration

È inoltre possibile registrare un client come singleton manualmente.

builder.Services.AddSingleton<IAmazonS3>(_ => new AmazonS3Client());

Riutilizzare il client non significa smettere di eliminare le risposte successive all'operazione. Riutilizzate il client per tutta la durata dell'applicazione, ma continuate a eliminare le risposte e i flussi restituiti dalle singole operazioni, come descritto in. Elimina le risposte e gli stream

Elimina le risposte e gli stream per liberare le connessioni

Alcuni oggetti di risposta SDK trasmettono un flusso di rete in tempo reale. L'esempio più comune è GetObjectResponse, che implementa IDisposable ed espone il contenuto dell'oggetto tramite la sua proprietà. ResponseStream La risposta mantiene una connessione HTTP aperta finché lo stream non viene letto completamente o la risposta non viene eliminata. Se si diffondono queste risposte (ad esempio, richiamando GetObject un ciclo senza eliminare ogni risultato), le connessioni aperte si accumulano fino all'esaurimento del pool di connessioni e la chiamata successiva viene bloccata. Questa è la causa delle segnalazioni di download che «si bloccano casualmente» o si bloccano sull'ennesimo oggetto.

Racchiudi sempre una risposta in streaming in una using dichiarazione e leggi o copia il relativo stream prontamente.

using Amazon.S3;
using Amazon.S3.Model;

// s3Client is a reused, long-lived client.
var request = new GetObjectRequest { BucketName = bucketName, Key = key };

using var response = await s3Client.GetObjectAsync(request);
await response.WriteResponseStreamToFileAsync(filePath, append: false, CancellationToken.None);

L'eliminazione della risposta e la sua eliminazione ResponseStream sono equivalenti; entrambe chiudono il flusso di rete sottostante e restituiscono la connessione al pool.

var metadata = await s3Client.GetObjectMetadataAsync(bucketName, key);
Console.WriteLine($"Size: {metadata.ContentLength} bytes");

Usa correttamente async/await

Nel moderno .NET, le operazioni di servizio in AWS SDK per .NET sono asincrone e restituiscono un. Task In .NET Framework esistono anche metodi sincroni, ma le chiamate asincrone hanno una scalabilità migliore e sono consigliate. Completa le operazioni con await e propagati async attraverso ogni livello del codice fino al punto di ingresso. Per ulteriori informazioni sulla programmazione asincrona con l'SDK, consulta. Programmazione asincrona

Il metodo seguente blocca la chiamata asincrona e può bloccare o interrompere il pool di thread.

// Anti-pattern: do not do this.
public GetObjectResponse Get(GetObjectRequest request)
{
    return s3Client.GetObjectAsync(request).Result;
}

Effettua invece il metodo e la chiamata. async await

public async Task<GetObjectResponse> GetAsync(GetObjectRequest request)
{
    return await s3Client.GetObjectAsync(request);
}

Raccomandazioni aggiuntive per il codice asincrono:

Configura la garbage collection .NET per AWS Lambda e Amazon ECS

Quando un contenitore sembra avere una «perdita di memoria», il garbage collector (GC) .NET potrebbe conservare la memoria recuperata per poterla riutilizzare. Di conseguenza, la memoria di processo può apparire elevata e stabile anche quando l'heap gestito non aumenta. Inoltre, il GC non rileva automaticamente il limite di memoria di un contenitore (il relativo limite cgroup). In un ambiente vincolato, l'heap potrebbe quindi aumentare verso la memoria dell'host anziché il limite del contenitore. Ciò può comportare la chiusura OutOfMemoryException o la chiusura del contenitore.

Per aiutare il GC a funzionare bene in ambienti limitati:

Per ulteriori informazioni su queste impostazioni, vedi Opzioni di configurazione del runtime per la garbage collection su learn.microsoft.com. Per indicazioni specifiche sull' AWS elaborazione, consulta il post sul blog di AWS Developer Tools Configuring .NET Garbage Collection for Amazon ECS e. AWS Lambda

Gestisci le connessioni HTTP e i limiti di connessione

In condizioni di throughput elevato, sono comuni due problemi relativi alla connessione. Il primo è l'apertura di troppe connessioni di breve durata. Ciò esaurisce le porte temporanee, lascia spazio ai socket e aumenta la latenza dell'handshake TCP TIME_WAIT e TLS. Il secondo è il numero insufficiente di connessioni disponibili, il che limita il parallelismo. Il riutilizzo di un singolo client di lunga durata (vediRiutilizza i client di servizio) è la base per un pool di connessioni sano, perché il pooling dipende dal client che viene riutilizzato.

Per regolare il numero di connessioni simultanee per endpoint, imposta la proprietà sulla configurazione del client. MaxConnectionsPerServer Quando questa proprietà è null (impostazione predefinita), si applica l'HttpClientHandlerimpostazione predefinita sottostante, che è effettivamente illimitata nel moderno .NET. Aumentalo solo quando molte richieste simultanee allo stesso endpoint hanno un collo di bottiglia nelle connessioni. Un buon punto di partenza è il numero massimo di richieste simultanee previste per endpoint. Impostarlo su un valore molto più elevato rispetto alle esigenze del carico di lavoro comporta uno spreco di socket senza migliorare la produttività.

using Amazon.S3;

var config = new AmazonS3Config
{
    MaxConnectionsPerServer = 50
};

var s3Client = new AmazonS3Client(config);

Se utilizzi già l'iniezione delle dipendenze, configura i tuoi clienti tramite. AWSSDK.Extensions.NETCore.Setup Questo è l'approccio consigliato quando si utilizza DI o si registrano diversi client di servizio. Centralizza la configurazione e semplifica l'iniezione e il test dei client. È possibile impostare i valori di configurazione dalla configurazione dell'applicazione anziché nel codice. Per ulteriori informazioni, consulta AWSSDK.Extensions.NETCore.Setup e iConfiguration.

Infine, limita il tuo parallelismo in modo da non avviare più operazioni simultanee di quelle consentite dal limite di connessione. Ad esempio, gate call con una SemaphoreSlim dimensione pari al limite di connessione:

var throttle = new SemaphoreSlim(50); // match MaxConnectionsPerServer
await throttle.WaitAsync(token);
try
{
    await s3Client.GetObjectAsync(request, token);
}
finally
{
    throttle.Release();
}

Configura timeout e tentativi

I timeout e i tentativi hanno un effetto diretto sulle prestazioni percepite. Un Timeout valore troppo alto consente a una richiesta bloccata per un lungo periodo di tempo. Quando un servizio sta già restituendo errori di limitazione, una politica di ripetizione aggressiva aggiunge più richieste e può peggiorare la limitazione. Scegliete una politica di ripetizione che soddisfi la tolleranza della vostra applicazione per quanto riguarda la latenza rispetto agli errori e lasciate che le eccezioni reali si propaghino invece di riprovare in modo da mascherare un blocco.

Per ulteriori informazioni sulle modalità di riprova e sulla Timeout proprietà (ReadWriteTimeoutsi applica solo a.NET Framework), insieme ad esempi su come impostarle, vedere. MaxErrorRetry Ritentativi e timeout

Ottimizza lo streaming e i trasferimenti di oggetti di grandi dimensioni (Amazon S3)

Per caricare e scaricare oggetti di grandi dimensioni o molti oggetti, utilizzate la TransferUtility classe nel Amazon.S3.Transfer namespace. Carica e scarica in parallelo utilizzando trasferimenti in più parti e gestisce flussi, parti e connessioni per te. È più veloce di un trasferimento a flusso singolo ed è il metodo consigliato per spostare oggetti di grandi dimensioni.

Diagnostica problemi di prestazioni

Quando analizzi un rallentamento, un blocco o una perdita apparente, i seguenti segnali ti aiutano a individuare rapidamente la causa: