Ridimensionamento software/hardware per un gran numero di richieste API esterne?

Question

Abbiamo un sistema che fornisce un numero di richieste, effettua un numero equivalente di chiamate a un'API di terze parti esterna. Dato che si tratta di un'attività associata all'I/O, al momento utilizziamo un pool di thread memorizzato nella cache di dimensione 20 per soddisfare queste richieste. Diversa dalle precedenti, è la soluzione ai:

usare meno macchine a più nuclei (meno context-switching, in grado di supportare più thread simultanei)

o

uso più macchine sfruttando commodity/hardware economico (scatole per pizza)

Il numero di richieste che riceviamo un giorno è dell'ordine di milioni di persone.

Stiamo usando Java, quindi i thread qui sono kernel, non "verdi".

altri punti/pensieri:

• Hadoop è comunemente usato per problemi di questa natura, ma questo deve essere in tempo reale contro lo stereotipo dati offline mining.
• Le richieste API richiedere da 200 ms a 2 secondi in media
• Non v'è stato condiviso tra le richieste
• Il partito terzo in questione è in grado di servire più richieste di quanto possiamo fuoco (pagamenti vendor).

Answer 1

Non è ovvio per me che siano necessarie più risorse (macchine più grandi o più macchine). Se stai parlando al massimo 10 milioni di richieste in un giorno che richiedono al massimo 2 secondi ciascuna, significa:

• ~ 110 richieste al secondo. Non è così veloce. Le richieste sono particolarmente grandi? O ci sono grandi raffiche? Stai eseguendo elaborazioni pesanti oltre alla distribuzione all'API di terze parti? Finora non mi hai fornito alcuna informazione che mi induca a credere che non sia possibile eseguire l'intero servizio su un singolo core. (Chiamalo tre delle macchine più piccole possibili se vuoi avere ridondanza n + 2)
• in media ~ 220 richieste attive. Di nuovo, non sembra un problema per una singola macchina, anche con un modello thread-per-request (in pool). Perché non espandi le dimensioni del tuo pool e lo chiami un giorno? Sono davvero esplosivi? (E i requisiti di latenza/affidabilità sono davvero stretti?) Hanno bisogno di un'enorme quantità di RAM mentre sono attivi?

Potrebbe fornire qualche informazione in più sul motivo per cui pensi di dover fare questa scelta?

Answer 2

Anziché utilizzare un numero elevato di thread, è possibile ottenere risultati migliori con l'I/O basato sugli eventi utilizzando node.js con gli avvertimenti che potrebbe significare una riscrittura grande e il fatto che node.js sia piuttosto giovane.

Questo SO article può essere di interesse.