Lentezza SSL in EC2

Question

Abbiamo installato la nostra app per binari su EC2. Nella nostra configurazione, abbiamo due proxy su piccole istanze dietro DNS round robin. Questi eseguono i servizi di bilanciamento del carico nginx per una farm in crescita dinamica e in diminuzione dei server Web. Ogni server Web esegue anche nginx con un gruppo di meticci. Qui il nginx si occupa del contenuto statico e del bilanciamento del carico dei meticci.

In ogni caso, il nostro traffico di grandi dimensioni è HTTPS. Abbiamo i 2 proxy che si prendono cura di SSL. Ho notato che il nostro throughput di rete in queste istanze si riduce a soli 60 Mbps circa. Per contrasto, nei test sono in grado di ottenere costantemente oltre 700 Mbps su una piccola istanza tramite il normale HTTP. In realtà, questo è lo stesso di quello che posso ottenere su una grande istanza. Simile a quello che i ragazzi della Scala Giusta hanno ottenuto in their testing. (Amazon dice che un piccolo diventa "moderato" I/O di rete, mentre un grande diventa "alto". Se dovessi speculare, penso che questo sia solo il loro modo di dire che ci sono più piccole istanze per ogni box fisico che condivide una scheda di rete Non sono sicuro se ciò significa che una grande ottiene un'interfaccia di rete dedicata, ma ne dubito.)

In fase di test, sono riuscito a ottenere un'istanza di grandi dimensioni per ottenere circa 250 Mbps SSL. Questo mi dice che la CPU o qualche altra risorsa è il collo di bottiglia. Tuttavia, i nostri grafici di monitoraggio non mostrano che la CPU dei nostri proxy è particolarmente occupata.

Le mie domande sono:

1. È il mio istinto su SSL essendo più lento a causa della CPU corretta e nostri grafici di monitoraggio sono sbagliate? O qualche altra risorsa potrebbe essere il fattore limitante?
2. Dovremmo solo prendere il costo aggiuntivo e mettere i proxy su istanze con CPU alta? O sarebbe meglio fare solo aggiungere più piccole istanze?
3. Dovremmo scaricare la terminazione SSL sui server web? Questo introduce un ulteriore problema, però: come si ottiene l'indirizzo IP del client nella nostra applicazione? In questo momento il nostro proxy lo imposta nell'intestazione X-FORWARDED-FOR, ma ovviamente questo non sarebbe possibile se non decodifica SSL.

Mi piacerebbe sapere di qualsiasi configurazione simile. Abbiamo armeggiato un po 'con il loro Elastic Load Balancer, ma penso che fondamentalmente ci metta nella stessa situazione del # 3 sopra. Qualcun altro ha fatto il passaggio a ELB e ha trovato che ne valeva la pena?

Answer 1

Si sta utilizzando la cache di sessione SSL fornita da nginx? Ciò può aiutare nginx a risparmiare sui cicli di rielaborazione costante della crittografia. Vedere http://wiki.nginx.org/NginxHttpSslModule#ssl_session_cache

Quale monitoraggio si sta utilizzando per determinare l'utilizzo della CPU? Il protocollo SSL è in genere molto intenso per la CPU.

Vorrei mantenere i proxy SSL come livello designato, in questo modo è possibile ridimensionare il costo della negoziazione di ssl separatamente da altri problemi.

Answer 2

SSL più lento: - true, quindi qualsiasi richiesta HTTP normale HTTPSSL, sarà più lenta.

Provare a creare un'installazione simile, nella LAN locale, in cui sono presenti 3 mongrel_clust e 2 server web. e controlla usando il caricatore di curl, con l'invio di circa 5k richieste.

se tutto va bene, va benissimo. potresti lavorare di più con i ragazzi EC2.

Answer 3

Sto usando SSL su Apache, che gestisce l'accesso al nostro repository Subversion su un'istanza Small Windows EC2. Durante i test, ho scoperto che l'accesso HTTPS era leggermente più lento di HTTP, ma è ovvio che la crittografia/decrittografia non è un processo istantaneo, come ci si aspetterebbe.

Se le metriche della CPU sono corrette e non viene visualizzato un carico eccessivo, l'implicazione è che la larghezza di banda è il fattore limitante; tuttavia, non riesco davvero a capire perché potresti ottenere 700+ Mbps su un'istanza HTTP, rispetto a solo 60Mbps su un'istanza HTTPS. A meno che le condizioni di test non fossero effettivamente identiche, naturalmente, e c'è qualcos'altro che accade all'interno dell'istanza HTTPS che non hai fattorizzato in ...

Ovviamente, le istanze più grandi ottengono una quota migliore dell'ampiezza di banda dell'host rispetto a Smalls: ce ne sono meno in competizione per la risorsa. Poiché la rete EC2 interna è Gigabit Ethernet, la possibilità di vedere 700 Mbps su un'istanza di grandi dimensioni è fattibile, supponendo che nessun'altra istanza di grandi dimensioni sullo stesso nodo stia facendo richieste di larghezza di banda simili. Per farlo uscire da una piccola istanza, dovresti essere davvero fortunato a correre in un host molto leggero. E in tal caso, non ci sarebbe alcuna garanzia che tu mantenga quel livello di prestazioni - non appena gli Smalls sono arrivati ​​online, la tua quota di banda disponibile inizierà a diminuire.

Penso che questo sia essenzialmente un problema di larghezza di banda di piccola istanza - l'aggiunta di più Smalls non aiuta necessariamente molto, perché non si ha il controllo su quale host si avviano; Le grandi istanze, tuttavia, ottengono una fetta maggiore della torta dell'ampiezza di banda e pertanto possono avere una disponibilità di capacità più coerente.