Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Best practice e modelli di progettazione: ottimizzazione delle prestazioni di Amazon S3
Le applicazioni possono facilmente raggiungere migliaia di transazioni al secondo come prestazioni delle richieste durante il caricamento e il recupero di risorse di storage da Amazon S3. Amazon S3 si ridimensiona automaticamente fino a tassi di richiesta elevati. Ad esempio, la tua applicazione può raggiungere almeno 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD richieste al secondo per prefisso Amazon S3 partizionato. Non esistono limiti al numero di prefissi in un bucket. Puoi migliorare le prestazioni in lettura o scrittura utilizzando la parallelizzazione. Ad esempio, se si creano 10 prefissi in un bucket Amazon S3 per parallelizzare le letture, è possibile scalare le prestazioni di lettura a 55.000 richieste di lettura al secondo. Allo stesso modo, è possibile ridimensionare le operazioni di scrittura scrivendo su più prefissi. Nelle operazioni di lettura e scrittura il dimensionamento avviene gradualmente, non è istantaneo, e le prestazioni effettive variano in base alle caratteristiche specifiche del carico di lavoro, ai modelli di utilizzo e alla configurazione del sistema. Sebbene Amazon S3 stia eseguendo il dimensionamento alla nuova frequenza di richieste più elevata, si potrebbero verificare alcuni errori 503 (Slow Down). Questi errori scompariranno al termine del ridimensionamento. Per ulteriori informazioni sulla creazione e sull'utilizzo dei prefissi, consulta [Organizzazione degli oggetti utilizzando i prefissi](using-prefixes.md).
Alcune applicazioni di data lake in Amazon S3 analizzano milioni o miliardi di oggetti per query eseguite su diversi petabyte di dati. Queste applicazioni data lake raggiungono velocità di trasferimento a singola istanza che massimizzano l'uso dell'interfaccia di rete per la loro istanza [Amazon](https://docs.aws.amazon.com/ec2/index.html) EC2, che può arrivare fino a Gb/s 100 su una singola istanza. Queste applicazioni poi aggregano throughput su più istanze per ottenere diversi terabit al secondo.
Altre applicazioni sono sensibili alla latenza, come le applicazioni di messaggistica sui social media. Queste applicazioni possono raggiungere latenze coerenti per piccoli oggetti (e first-byte-out latenze per oggetti più grandi) di circa 100-200 millisecondi.
Altri AWS servizi possono inoltre contribuire ad accelerare le prestazioni per diverse architetture applicative. Ad esempio, se desideri velocità di trasferimento più elevate su una singola connessione HTTP o latenze di un millisecondo, usa Amazon [o](https://docs.aws.amazon.com/cloudfront/index.html) Amazon per la memorizzazione nella [cache ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) con Amazon CloudFront S3.
Inoltre, se desideri trasferimenti dei dati veloci su lunghe distanze tra un client e un bucket S3, utilizza [Configurazione di trasferimenti veloci e sicuri di file con Amazon S3 Transfer Acceleration](transfer-acceleration.md). Transfer Acceleration utilizza le edge location distribuite a livello globale per accelerare il trasporto dei dati su distanze geografiche. CloudFront Se il tuo carico di lavoro Amazon S3 utilizza la crittografia lato server con AWS KMS, consulta [AWS KMS Limits](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) nella AWS Key Management Service Developer Guide per informazioni sulle frequenze di richiesta supportate per il tuo caso d'uso.
Gli argomenti seguenti presentano le linee guida e i modelli di progettazione per le best practice per ottimizzare le prestazioni per le applicazioni che utilizzano Amazon S3. Per le informazioni più aggiornate sull'ottimizzazione delle prestazioni per Amazon S3, consulta [Linee guida per le prestazioni di Amazon S3](optimizing-performance-guidelines.md) e [Modelli di progettazione delle prestazioni per Amazon S3](optimizing-performance-design-patterns.md).
**Nota**
Per ulteriori informazioni sull'utilizzo della classe di archiviazione Amazon S3 Express One Zone con bucket di directory, consulta [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone) e [Operazioni con i bucket di directory](directory-buckets-overview.md).
**Topics**
+ [Linee guida per le prestazioni di Amazon S3](optimizing-performance-guidelines.md)
+ [Modelli di progettazione delle prestazioni per Amazon S3](optimizing-performance-design-patterns.md)
# Linee guida per le prestazioni di Amazon S3
Per sviluppare applicazioni che caricano e recuperano oggetti da Amazon S3, segui le nostre linee guida sulle best practice per ottimizzare le prestazioni. Offriamo anche [Modelli di progettazione delle prestazioni per Amazon S3 ](optimizing-performance-design-patterns.md) più dettagliati.
Per ottenere prestazioni ottimali per le applicazioni su Amazon S3, consigliamo di adottare le linee guida seguenti.
**Topics**
+ [Misurare le prestazioni](#optimizing-performance-guidelines-measure)
+ [Scalare orizzontalmente le connessioni di archiviazione](#optimizing-performance-guidelines-scale)
+ [Utilizza i recuperi con intervallo di byte](#optimizing-performance-guidelines-get-range)
+ [Nuovi tentativi di richieste per applicazioni sensibili alla latenza](#optimizing-performance-guidelines-retry)
+ [Combina Amazon S3 (storage) e Amazon EC2 (elaborazione) nello stesso Regione AWS](#optimizing-performance-guidelines-combine)
+ [Utilizza Amazon S3 Transfer Acceleration per ridurre al minimo la latenza causata dalla distanza](#optimizing-performance-guidelines-acceleration)
+ [Utilizza la versione più recente di AWS SDKs](#optimizing-performance-guidelines-sdk)
## Misurare le prestazioni
Quando ottimizzi le prestazioni, devi verificare i requisiti che riguardano il throughput della rete, la CPU e la DRAM. A seconda della combinazione di esigenze per queste risorse diverse, può essere utile valutare più tipi di istanza [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html). Per ulteriori informazioni sui tipi di istanza, consulta [Tipi di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) nella *Guida dell'utente di Amazon EC2*.
Durante la misurazione delle prestazioni, è utile anche verificare i tempi, la latenza e la velocità del trasferimento dei dati DNS utilizzando strumenti di analisi HTTP.
Per comprendere i requisiti relativi alle prestazioni e ottimizzare le prestazioni dell'applicazione, puoi anche monitorare le risposte di errore 503 che ricevi. Il monitoraggio di determinate metriche delle prestazioni può comportare spese aggiuntive. Per ulteriori informazioni, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
### Monitoraggio del numero di risposte all'errore di stato 503 (Rallentamento)
Per monitorare il numero di risposte all'errore di stato 503 che ricevi, puoi utilizzare una delle seguenti opzioni:
+ Usa i parametri delle CloudWatch richieste di Amazon per Amazon S3. Le metriche della CloudWatch richiesta includono una metrica per 5xx risposte allo stato. Per ulteriori informazioni sui parametri di richiesta di CloudWatch , consulta [Monitoraggio delle metriche con Amazon CloudWatch](cloudwatch-monitoring.md).
+ Utilizza il conteggio dell'errore 503 (Servizio non disponibile) disponibile nella sezione delle metriche avanzate di Amazon S3 Storage Lens. Per ulteriori informazioni, consulta [Utilizzo dei parametri di S3 Storage Lens per migliorare le prestazioni](storage-lens-detailed-status-code.md).
+ Utilizza la registrazione degli accessi al server Amazon S3 Con la registrazione degli accessi al server, puoi filtrare ed esaminare tutte le richieste che ricevono risposte 503 (Errore interno). Puoi anche utilizzare Amazon Athena per analizzare i log. Per ulteriori informazioni sulla registrazione degli accessi al server, consulta [Registrazione delle richieste con registrazione dell'accesso al server](ServerLogs.md).
Monitorando il numero del codice di errore di stato HTTP 503, spesso puoi ottenere informazioni dettagliate preziose su quali prefissi, chiavi o bucket ricevono il maggior numero di richieste di limitazione (della larghezza di banda della rete).
## Scalare orizzontalmente le connessioni di archiviazione
Distribuire le richieste su più connessioni è uno schema di progettazione comune per scalare orizzontalmente le prestazioni. Se devi creare applicazioni ad alte prestazioni, pensa ad Amazon S3 come un sistema distribuito di dimensioni molto grandi, non un singolo endpoint di rete come un server di storage tradizionale. Puoi ottenere prestazioni ottimali inviando più richieste simultanee ad Amazon S3. Distribuisci queste richieste su connessioni separate per massimizzare la larghezza di banda accessibile da Amazon S3. Amazon S3 non impone limiti al numero di connessioni effettuate al bucket.
## Utilizza i recuperi con intervallo di byte
Utilizzando l'intestazione HTTP `Range` in una richiesta [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html), puoi recuperare un intervallo di byte da un oggetto, trasferendo solo la parte specificata. Puoi utilizzare connessioni simultanee ad Amazon S3 per recuperare diversi intervalli di byte all'interno dello stesso oggetto. Questa operazione ti permette di ottenere un throughput aggregato superiore rispetto a una singola richiesta whole-object. Recuperare range minori da oggetti più grandi permette inoltre alla tua applicazione di migliorare i tempi di ripetizione quando le richieste sono interrotte. Per ulteriori informazioni, consulta [Download di oggetti](download-objects.md).
Se gli oggetti sono oggetti PUT che utilizzano un caricamento in più parti, è buona pratica trasformarli in oggetti GET nelle stesse dimensioni della parte (o almeno allineati ai limiti della parte) per ottenere le prestazioni migliori. Le richieste GET possono rivolgersi direttamente alle singole parti; ad esempio, `GET ?partNumber=N.`
## Nuovi tentativi di richieste per applicazioni sensibili alla latenza
I timeout e i tentativi aggressivi aiutano a mantenere la latenza uniforme. Poiché Amazon S3 opera su vasta scala, se la prima richiesta è lenta, un nuovo tentativo di richiesta adotterà un percorso diverso e riuscirà rapidamente. AWS SDKs Dispongono di valori di timeout e tentativi configurabili che è possibile regolare in base alle tolleranze dell'applicazione specifica.
## Combina Amazon S3 (storage) e Amazon EC2 (elaborazione) nello stesso Regione AWS
Sebbene i nomi dei bucket S3 siano univoci a livello globale, ogni bucket viene archiviato in una regione che sceglierai durante la creazione del bucket stesso. Per saperne di più sulle linee guida per la denominazione dei bucket, consulta [Panoramica sui bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) e [Regole di denominazione dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html). Per ottimizzare le prestazioni, ti consigliamo di accedere al bucket dalle istanze Amazon EC2 nello stesso modo, quando possibile. Regione AWS Questa operazione permette di ridurre la latenza e i costi di trasferimento dei dati.
Per ulteriori informazioni sui costi dl trasferimento dei dati, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
## Utilizza Amazon S3 Transfer Acceleration per ridurre al minimo la latenza causata dalla distanza
[Configurazione di trasferimenti veloci e sicuri di file con Amazon S3 Transfer Acceleration](transfer-acceleration.md) gestisce trasferimenti di file veloci, facili e sicuri su vaste distanze geografiche tra il client e un bucket S3. Transfer Acceleration sfrutta le edge location distribuite a livello globale di [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html). Quando arrivano in una edge location, i dati vengono instradati ad Amazon S3 attraverso un percorso di rete ottimizzato. Transfer Acceleration è ideale per il trasferimento regolare di gigabyte e terabyte di dati sui diversi continenti. È inoltre utile per i clienti che effettuano il caricamento in un bucket centralizzato da tutto il mondo.
È possibile utilizzare lo [strumento di confronto della velocità di accelerazione dei trasferimenti di Amazon S3](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html) per confrontare le velocità di caricamento accelerate e non accelerate nelle Regioni di Amazon S3. Questo strumento utilizza caricamenti in più parti per trasferire un file dal browser in uso a diverse regioni Amazon S3 con e senza l'utilizzo di Amazon S3 Transfer Acceleration.
## Utilizza la versione più recente di AWS SDKs
AWS SDKs Forniscono supporto integrato per molte delle linee guida consigliate per l'ottimizzazione delle prestazioni di Amazon S3. SDKs Forniscono un'API più semplice per sfruttare Amazon S3 dall'interno di un'applicazione e vengono regolarmente aggiornate per seguire le best practice più recenti. Ad esempio, SDKs includono la logica di inclusione che consente di riprovare automaticamente le richieste relative agli errori HTTP 503 e investono in codice per rispondere e adattarsi alle connessioni lente.
Forniscono SDKs anche il [Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html), che automatizza le connessioni a scalabilità orizzontale per soddisfare migliaia di richieste al secondo, utilizzando richieste con intervallo di byte, ove appropriato. È importante utilizzare la versione più recente di per ottenere le più recenti funzionalità di ottimizzazione delle AWS SDKs prestazioni.
Puoi inoltre ottimizzare le prestazioni quando utilizzi le richieste dell'API REST HTTP. Quando si utilizza l'API REST, è necessario seguire le stesse best practice che fanno parte di SDKs. Consenti i timeout e i tentativi sulle richieste lente e le connessioni multiple per permettere il recupero dei dati degli oggetti in parallelo. Per informazioni sull'utilizzo della REST API, consulta la [Documentazione di riferimento delle API di Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
# Modelli di progettazione delle prestazioni per Amazon S3
Nel progettare applicazioni per caricare e recuperare oggetti da Amazon S3, utilizza i nostri schemi di progettazione delle best practice per ottenere prestazioni ottimali per l'applicazione. Offriamo anche [Linee guida per le prestazioni di Amazon S3 ](optimizing-performance-guidelines.md), che puoi prendere in considerazione quando pianifichi l'architettura dell'applicazione.
Per ottimizzare le prestazioni, puoi utilizzare i seguenti schemi di progettazione.
**Topics**
+ [Utilizzo della cache per i contenuti a cui si accede di frequente](#optimizing-performance-caching)
+ [Timeout e retry per applicazioni sensibili alla latenza](#optimizing-performance-timeouts-retries)
+ [Scalabilità orizzontale e parallelizzazione delle richieste per un elevato throughput](#optimizing-performance-parallelization)
+ [Utilizzo di Amazon S3 Transfer Acceleration per accelerare i trasferimenti di dati geograficamente eterogenei](#optimizing-performance-acceleration)
+ [Ottimizzazione per carichi di lavoro a elevata frequenza di richieste](#optimizing-performance-high-request-rate)
## Utilizzo della cache per i contenuti a cui si accede di frequente
Molte applicazioni che archiviano dati in Amazon S3 fungono da “set di lavoro” dei dati richiesti ripetutamente dagli utenti. Se un carico di lavoro invia richieste GET ripetute per un set comune di oggetti, puoi utilizzare una cache come [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) ElastiCache, [Amazon](https://docs.aws.amazon.com/elasticache/index.html) o [AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/index.html)per ottimizzare le prestazioni. L'adozione corretta di una cache può portare a una bassa latenza e a tassi di trasferimento dei dati più alti. Le applicazioni che utilizzano il caching inviano anche meno richieste dirette ad Amazon S3, riducendo i costi delle richieste.
Amazon CloudFront è una rete di distribuzione rapida dei contenuti (CDN) che memorizza in modo trasparente nella cache i dati di Amazon S3 in un ampio set di punti di presenza distribuiti geograficamente (). PoPs Quando è possibile accedere agli oggetti da più regioni o tramite Internet, CloudFront consente di memorizzare i dati nella cache in prossimità degli utenti che accedono agli oggetti. In questo modo, è possibile distribuire contenuti Amazon S3 comuni con prestazioni elevate. Per informazioni in merito CloudFront, consulta l'[Amazon CloudFront Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/).
Amazon ElastiCache è una cache gestita in memoria. Con ElastiCache, puoi effettuare il provisioning di istanze Amazon EC2 che memorizzano oggetti nella cache. Il caching porta alla riduzione di grandezza della latenza GET e ad aumenti sostanziali nel throughput del download. Per utilizzarlo ElastiCache, è necessario modificare la logica dell'applicazione per popolare la cache con oggetti caldi e verificare la presenza di oggetti caldi nella cache prima di richiederli da Amazon S3. Per esempi di utilizzo ElastiCache per migliorare le prestazioni di Amazon S3 GET, consulta il post sul blog [Turbocharge Amazon S3 with Amazon](https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/) for Redis. ElastiCache
AWS Elemental MediaStore è un sistema di caching e distribuzione dei contenuti creato specificamente per i flussi di lavoro video e la distribuzione di contenuti multimediali da Amazon S3. MediaStore fornisce uno end-to-end spazio di archiviazione APIs specifico per i video ed è consigliato per carichi di lavoro video sensibili alle prestazioni. [Per informazioni in merito MediaStore, consulta la Guida per l'utente.AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/ug/)
## Timeout e retry per applicazioni sensibili alla latenza
In alcune situazioni un'applicazione riceve una risposta da Amazon S3 che indica che è necessario un nuovo tentativo. Amazon S3 mappa i nomi dei bucket e degli oggetti ai dati degli oggetti a essi associati. Se un'applicazione genera alti tassi di richiesta (in genere tassi sostenuti di oltre 5.000 richieste al secondo per un piccolo numero di oggetti) potrebbe ricevere risposte di *rallentamento* HTTP 503. Se si verifica questo errore, ogni SDK AWS implementa la logica di tentativo automatica utilizzando il backoff esponenziale. Se non stai utilizzando un SDK AWS , quando ricevi un errore HTTP 503 è necessario implementare la logica di tentativo. Per informazioni sulle tecniche di back-off, consulta [Retry behavior nella *AWS SDKs and Tools* Reference](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) Guide.
Amazon S3 si ridimensiona automaticamente in risposta a nuovi tassi di richiesta prolungati, ottimizzando dinamicamente le prestazioni. Mentre Amazon S3 ottimizza internamente per sostenere un nuovo tasso di richieste, riceverai temporaneamente risposte di richiesta HTTP 503 fino al completamento dell'ottimizzazione. Dopo che Amazon S3 ha ottimizzato internamente le prestazioni per il nuovo tasso di richiesta, tutte le richieste vengono in genere gestite senza nuovi tentativi.
Per le applicazioni sensibili alla latenza, Amazon S3 consiglia di monitorare e ritentare in modo aggressivo le operazioni più lente. Nel ritentare una richiesta, consigliamo di utilizzare una nuova connessione ad Amazon S3 e di eseguire una nuova ricerca DNS.
Quando effettui richieste di dimensioni grandi e variabili (ad esempio, oltre 128 MB), consigliamo di tracciare il throughput raggiunto e di ritentare il 5 percento più lento delle richieste. Quando effettui richieste più piccole (ad esempio, meno di 512 KB) dove le latenze medie sono spesso dell'ordine di decine di millisecondi, una buona linea guida è ritentare un'operazione GET o PUT dopo 2 secondi. Se sono necessari tentativi aggiuntivi, la best practice è di effettuare il backoff. Ad esempio, consigliamo di emettere un tentativo dopo 2 secondi e un secondo tentativo dopo 4 secondi aggiuntivi.
Se l'applicazione effettua richieste a dimensione fissa ad Amazon S3, il tempo di risposta per ogni richiesta sarà più costante. In questo caso, una strategia semplice è identificare l'1 percento più lento delle richieste e ritentarle. Anche un singolo tentativo è efficace nella riduzione della latenza.
Se utilizzi AWS Key Management Service (AWS KMS) per la crittografia lato server, consulta [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) nella *Guida per gli AWS Key Management Service sviluppatori* per informazioni sulle frequenze di richiesta supportate per il tuo caso d'uso.
## Scalabilità orizzontale e parallelizzazione delle richieste per un elevato throughput
Amazon S3 è un sistema distribuito di dimensioni molto grandi. Per sfruttarne a pieno la capacità di dimensionamento, consigliamo di ridimensionare orizzontalmente le richieste parallele agli endpoint del servizio Amazon S3. Oltre a distribuire le richieste in Amazon S3, questo tipo di approccio al dimensionamento permette di distribuire il carico su più percorsi nella rete.
Per i trasferimenti a throughput elevato, Amazon S3 consiglia di utilizzare applicazioni che usano più connessioni a dati GET o PUT in parallelo. Ad esempio, questo è supportato da [Amazon S3 Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html) nell'SDK AWS Java e la maggior parte degli altri AWS SDKs fornisce costrutti simili. Per alcune applicazioni, puoi raggiungere connessioni parallele lanciando simultaneamente richieste multiple in diversi thread dell'applicazione o in diverse istanze dell'applicazione. Il miglior approccio da adottare dipende dall'applicazione e dalla struttura degli oggetti a cui accedi.
Puoi utilizzare il AWS SDKs per emettere direttamente le richieste GET e PUT anziché utilizzare la gestione dei trasferimenti nell'SDK. AWS Questo approccio ti permette di ottimizzare il carico di lavoro in modo più diretto senza rinunciare al supporto degli SDK per i tentativi e la gestione delle risposte HTTP 503 che potrebbero verificarsi. Come regola generale, quando scarichi oggetti di grandi dimensioni da Amazon S3, ti suggeriamo di effettuare richieste simultanee per massimizzare il throughput di rete e ottimizzare le prestazioni di download. È possibile ottenere questo risultato richiedendo intervalli di byte specifici dell'oggetto o scaricando contemporaneamente singole parti di un oggetto composto da più parti. Questo approccio di download parallelo consente di utilizzare appieno la capacità della scheda di interfaccia di rete (NIC). Per gli oggetti caricati utilizzando il caricamento in più parti, consigliamo di scaricarli utilizzando le stesse dimensioni delle parti o di allineare le richieste ai limiti della parte originale per ottenere prestazioni ottimali. Questo metodo di download simultaneo offre un throughput aggregato più elevato rispetto alle richieste relative a singoli oggetti interi.
La misurazione delle prestazioni è importante quando ottimizzi il numero di richieste da emettere simultaneamente. Consigliamo di iniziare con un richiesta alla volta. Misura la larghezza di banda della rete raggiunta e l'uso delle altre risorse che la tua applicazione utilizza nell'elaborazione dei dati. Puoi quindi identificare la risorsa con un collo di bottiglia (ossia, la risorsa con l'utilizzo più elevato) e di conseguenza il numero di richieste che possono essere utili. Ad esempio, se elaborare una richiesta alla volta porta a un utilizzo della CPU del 25 percento, questo dato suggerisce che possono essere emesse fino a quattro richieste simultanee. La misurazione è essenziale ed è utile per confermare l'utilizzo della risorsa quando il tasso di richiesta aumenta.
Se l'applicazione invia richieste direttamente ad Amazon S3 utilizzando l'API REST, ti consigliamo di utilizzare un pool di connessioni HTTP e di riutilizzare ogni connessione per una serie di richieste. Evitare la configurazione della connessione per richiesta elimina la necessità di eseguire handshake slow-start su TCP e Secure Sockets Layer (SSL) su ogni richiesta. Per informazioni sull'utilizzo dell'API REST, consulta la [Documentazione di riferimento delle API di Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
Infine, è utile considerare con attenzione DNS e verificare accuratamente che le richieste vengano distribuite su un ampio pool di indirizzi IP di Amazon S3. Le query DNS per Amazon S3 passano per un elenco di grandi dimensioni di endpoint IP. Ma effettuare il caching dei resolver o del codice dell'applicazione che riutilizza un singolo indirizzo IP non trae vantaggio dalla diversità degli indirizzi e dal bilanciamento del carico che ne deriva. Utilità di rete come lo strumento a riga di comando `netstat` possono mostrare gli indirizzi IP utilizzati per la comunicazione con Amazon S3 e forniamo linee guida per le configurazioni DNS da utilizzare. Per ulteriori informazioni su queste linee guida, consulta la sezione [Esecuzione di richieste](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html) nella *documentazione di riferimento delle API di Amazon S3*.
## Utilizzo di Amazon S3 Transfer Acceleration per accelerare i trasferimenti di dati geograficamente eterogenei
[Configurazione di trasferimenti veloci e sicuri di file con Amazon S3 Transfer Acceleration](transfer-acceleration.md) è efficace nel ridurre o eliminare la latenza causata dalla distanza geografica tra client lontani a livello globale e un'applicazione locale che utilizza Amazon S3. Transfer Acceleration utilizza le edge location distribuite a livello globale per il trasporto dei dati. CloudFront La rete AWS perimetrale ha punti di presenza in più di 50 località. Oggi viene utilizzato per distribuire contenuti CloudFront e fornire risposte rapide alle query DNS effettuate su [Amazon Route 53](https://docs.aws.amazon.com/route53/index.html).
La rete edge permette anche di accelerare i trasferimenti dei dati da e verso Amazon S3. È ideale per le applicazioni che trasferiscono i dati tra continenti, dispongono di connessioni a Internet veloci e utilizzano oggetti di grandi dimensioni o hanno molti contenuti da caricare. Quando arrivano in una edge location, i dati vengono instradati ad Amazon S3 su un percorso di rete ottimizzato. In generale, più lontano ti trovi da una regione Amazon S3, maggiore è il miglioramento della velocità che otterrai utilizzando Transfer Acceleration.
Puoi configurare Transfer Acceleration su bucket nuovi o esistenti. Puoi utilizzare un endpoint Amazon S3 Transfer Acceleration separato per AWS utilizzare le edge location. Il modo migliore per verificare se Transfer Acceleration migliora le prestazioni delle richieste client consiste nell'utilizzare lo [strumento Speed Comparison di Amazon S3 Transfer Acceleration](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html). Le configurazioni e le condizioni della rete variano in base al momento e alla località. Vengono quindi addebitati solo i trasferimenti in cui Amazon S3 Transfer Acceleration può potenzialmente migliorare le prestazioni di caricamento. Per informazioni sull'utilizzo di Transfer Acceleration con diversi, consulta. AWS SDKs [Abilitazione e utilizzo di S3 Transfer Acceleration](transfer-acceleration-examples.md)
## Ottimizzazione per carichi di lavoro a elevata frequenza di richieste
Le applicazioni che generano frequenze di richiesta elevate ad Amazon S3 richiedono modelli di progettazione specifici per ottenere prestazioni ottimali. Quando l'applicazione genera costantemente più di 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD richieste al secondo per prefisso, è necessario implementare strategie per distribuire le richieste e gestire il comportamento di scalabilità.
Amazon S3 scala automaticamente le risorse per soddisfare frequenze di richiesta più elevate, ma questo dimensionamento avviene gradualmente. Durante il processo di dimensionamento, potresti ricevere risposte HTTP 503 (Slow Down). Queste risposte sono temporanee e indicano che Amazon S3 sta ottimizzando i sistemi interni per il nuovo modello di richiesta. Una volta completato il dimensionamento, le richieste verranno eseguite senza limitazione (della larghezza di banda della rete).
Per ottimizzare le prestazioni per i carichi di lavoro con frequenza di richiesta elevata, considera le seguenti strategie:
+ **Distribuisci le richieste su più prefissi**: utilizza un modello di prefisso randomizzato o sequenziale per distribuire le richieste su più partizioni. Ad esempio, invece di utilizzare nomi di oggetti sequenziali come `log-2024-01-01.txt`, utilizza prefissi randomizzati come `a1b2/log-2024-01-01.txt`. Questo aiuta Amazon S3 a distribuire il carico in modo più efficace.
+ **Implementa il backoff esponenziale per gli errori 503**: quando ricevi risposte HTTP 503, implementa la logica dei tentativi con backoff esponenziale. Inizia con un breve ritardo e aumenta gradualmente il tempo di attesa tra un tentativo e l’altro. AWS SDKs Include una logica di riprova integrata che lo gestisce automaticamente.
+ **Monitora i modelli di richiesta**: utilizza i CloudWatch parametri di Amazon per monitorare i tassi di richiesta e i tassi di errore. Presta particolare attenzione alle metriche degli errori 5xx, che possono indicare quando l’applicazione sta raggiungendo o superando gli attuali limiti di dimensionamento.
+ **Aumenta gradualmente la frequenza di richiesta**: quando si avviano nuove applicazioni o aumenta significativamente la frequenza di richiesta, è opportuno aumentare gradualmente il traffico nel tempo anziché raggiungere immediatamente le frequenze di picco. Ciò consente ad Amazon S3 di scalare in modo proattivo e riduce la probabilità di limitazione (della larghezza di banda della rete).
+ **Utilizza più connessioni**: distribuisci le richieste su più connessioni HTTP per massimizzare il throughput e ridurre l’impatto di ogni singolo problema di connessione.
Per le applicazioni che richiedono prestazioni elevate e coerenti, prendi in considerazione l’utilizzo di Amazon S3 Express One Zone, progettato per applicazioni che richiedono latenze nell’ordine di millisecondi e può supportare centinaia di migliaia di richieste al secondo. Per ulteriori informazioni, consulta [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone).