Sito Web di Azure lento a servire JS/CSS statico ma non binario

Question

Possiedo un sito Web/app Web Azure che è incredibilmente lento a servire file JS e CSS statici ma sembra perfettamente funzionante con binario.

Per verificare il problema che ho caricato due file 30MB, uno big.js e l'altro big.rar. Il file JS viene scaricato a circa 100 KB/s se sono fortunato. Il file RAR viene scaricato a circa 4.000 KB/s. I risultati sono estremamente coerenti.

Ho controllato in Fiddler e la compressione gzip si sta verificando in entrambi i casi. Come previsto, il file JS viene inviato con il tipo MIME application/x-javascript mentre il file RAR viene servito come application/octet-stream.

Non riesco a capire questo: perché IIS servirebbe un tipo di contenuto statico molto più lento di un altro?

Answer 1

Abbiamo riscontrato questo problema ed è stato possibile risolverlo con l'aiuto di Azure Support Team. Il problema era che i file lenti usavano TransferEncoding: Chuncked. Hanno suggerito di forzare la compressione statica per ovviare a questo problema.

abbiamo dovuto aggiungere quanto segue a <system.webServer>:

<serverRuntime enabled="true" frequentHitThreshold="1" frequentHitTimePeriod="00:00:20" /> 

Answer 2

sembra che è stato un problema su IIS 8.5 e non solo specifici Azure.

Ora il servizio app upgrade to Windows Server 2016 looks complete e questa soluzione alternativa non dovrebbero essere necessari.

Answer 3

di approfondire la risposta di John Tseng: (da here)

Come si è visto in precedenza, IIS 7 cache le versioni compresse di file statici. Quindi, se arriva una richiesta per un file statico la cui versione compressa è già nella cache, non è necessario comprimerla ancora .

Ma cosa succede se non ci sono versioni compresse nella cache? IIS 7 comprimerà immediatamente il file e lo metterà nella cache? La risposta è sì, ma solo se il file viene richiesto frequentemente. Con non comprime i file richiesti solo di rado, IIS 7 salva l'utilizzo della CPU e lo spazio della cache.

Per impostazione predefinita, un file viene considerato richiesto frequentemente se è richiesto due o più volte per 10 secondi.

Quindi, il motivo per cui gli utenti vengono serviti in una versione non compressa del file javascript è perché non ha soddisfatto la soglia predefinita per la compressione; in altre parole, il file javascript non è stato richiesto 2 volte in 10 secondi.

Per controllare questo, è necessario modificare un attributo sull'elemento <serverRuntime>, che controlla la compressione: frequentHitThreshold.Affinché il file da comprimere quando viene richiesto una volta, cambiare il vostro elemento <serverRuntime> a guardare come questo:

<serverRuntime enabled="true" frequentHitThreshold="1" /> 

questo sarà leggermente influire sulla prestazioni della CPU se si dispone di molti file JavaScript che vengono serviti e si deve gli utenti abbastanza spesso, ma probabilmente se gli utenti hanno abbastanza spesso da influenzare la CPU dalla compressione di questi file, allora sono già compressi e memorizzati nella cache!