6

Due domande su ELB EC2:EC2 problemi di prestazioni ELB

Per prima cosa eseguire correttamente i test JMeter. Ho trovato il seguente http://osdir.com/ml/jmeter-user.jakarta.apache.org/2010-04/msg00203.html, che in pratica dice di impostare -Dsun.net.inetaddr.ttl = 0 all'avvio di JMeter (che è facile) e il secondo punto è che il routing è per IP non per richiesta. Quindi, a parte l'avvio di una fattoria di istanze di jmeter, non vedo come aggirarlo. Qualsiasi idea è ben accetta o forse sto leggendo male la spiegazione (?)

Inoltre, ho un servizio Web che sta effettuando una chiamata lato server a un altro servizio Web in java (e entrambi dietro ELB), quindi Sto usando HttpClient ed è MultiThreadedHttpConnectionManager, dove fornisco alcune route di grandi dimensioni al valore host nel gestore connessioni. E mi chiedo se questo interromperà il comportamento di bilanciamento del carico ELB perché le connessioni sono memorizzate nella cache (e anche che tutte le richieste provengono dalla stessa macchina). Posso passare a utilizzare ogni volta un nuovo HttpClient (tipo di lame) ma questo non aggira il fatto che tutte le richieste provengono da un piccolo numero di host.

Backstory: Sono in procinto di perf testare un servizio utilizzando ELB su EC2 e il traffico non è distribuito in modo uniforme (la maggior parte del traffico a 1-2 nodi, quasi nessun traffico a 1 nodo, nessun traffico a un 4o nodo). E così i problemi di cui sopra sono i possibili colpevoli che ho identificato.

risposta

1

Ho avuto problemi molto simulati. Una cosa è che l'ELB non scala bene sotto il carico di scoppio. Quindi, quando stai provando a testarlo, non si sta scalando immediatamente. Ci vuole un sacco di tempo per farlo salire. Un'altra cosa che è un inconveniente è il fatto che utilizza un CNAME come DNS look up. Questo da solo ti rallenterà. Ci sono più problemi di prestazioni che puoi ricercare.

Il mio consiglio è di usare haproxy. Hai molto più controllo e ti piacerà la performance. Sono stato molto soddisfatto. Uso il battito cardiaco per impostare un server ridondante e sono a posto.

Inoltre, se si pianifica di eseguire SSL con ELB, ne soffrirai di più perché ho trovato le prestazioni inferiori alla pari.

Spero che questo aiuti alcuni. Quando si tratta di questo, AWS mi ha detto personalmente che il test di carico del ELB non funziona davvero, e se stai pianificando di lanciare con una grande quantità di carico, devi dire loro che possono ridimensionarti in anticipo .

+0

Non sono sicuro se quello che sto facendo conta un sacco di carico, ma come 150-200 QPS a un API REST, nessun SSL. Non mi aspetto che lo stesso ELB si riduca (spero che 1 ELB possa gestire 150QPS), ma mi aspetto che distribuisca uniformemente il carico attraverso le caselle, senza dover avere tempo di accelerazione. Potresti commentarlo? – Kevin

+0

Sì. Ho avuto lo stesso problema e penso che il carico sia distribuito solo se ne hai bisogno. L'ELB non sembra coerente quando lo fa. Ti consiglierei di nuovo di guardare a haproxy, ha la possibilità di fare una distribuzione round robin che sarebbe più vicina a ciò di cui hai bisogno. Mi piacciono molto i servizi AWS, ma la scatola nera di ELB è troppo difficile da gestire IMO. – chantheman

+0

Un'altra cosa, se si sta inviando tutto il carico da un IP, potrebbe anche causare problemi con la distribuzione del carico. – chantheman

1

Non si dice quante istanze jmeter si sta eseguendo, ma nella mia esperienza dovrebbe essere circa il doppio del numero di AZ che si sta ridimensionando. Anche in questo caso, probabilmente vedrai carichi sbilanciati - è molto insolito vedere il carico ridimensionato esattamente nella tua flotta di back-end.

È possibile aiutare (un po ') eseguendo le istanze jmeter in regioni diverse.

Un altro fattore è la durata del test. I ELB richiedono un po 'di tempo per adattarsi - puoi generalmente dire quante istanze sono in esecuzione facendo un nslookup contro il nome ELB. Comprendi i tuoi schemi di ridimensionamento e costruisci test attorno a loro. Quindi, se occorrono 20 minuti per aggiungere un'altra istanza al pool ELB, includere un riscaldamento di 25-30 minuti per il test. Inoltre, AWS può "pre-riscaldare" il pool ELB, se necessario.

Se la dimensione del pool ELB è sufficiente per il test e può verificare che il pool non cambi durante l'esecuzione di test, è sempre possibile provare a eseguire i test direttamente contro gli IP ELB, ad esempio bilanciando manualmente il traffico.

Non sono sicuro di cosa ci si aspetta che accada con il secondo livello di chiamate: se si sta aprendo una connessione e riutilizzandola, non c'è ovviamente modo di ridimensionarla attraverso le istanze senza chiudere & aprendo la connessione. Queste chiamate sono in esecuzione sullo stesso set di server o su un set diverso? È possibile creare un ELB interno e utilizzare tale endpoint per connettersi, ma non sono sicuro che ciò possa essere d'aiuto nello scenario che hai descritto.