Mise à l'échelle logicielle/matérielle pour un grand nombre de demandes d'API externes?

Question

Nous avons un système qui donne un lot de demandes, fait un nombre équivalent d'appels à une API tierce externe. Étant donné qu'il s'agit d'une tâche liée aux E/S, nous utilisons actuellement un pool de threads mis en cache de taille 20 pour répondre à ces demandes. Autre que ci-dessus, est une solution à:

utiliser moins de machines avec d'autres noyaux (moins contexte de commutation, capable de supporter plusieurs fils parallèles)

ou

utilisation plus machines en tirant parti du matériel bon marché/à bon marché (boîtes à pizza)

Le nombre de demandes que nous recevons par jour est de l'ordre de des millions.

Nous utilisons Java, les threads ici sont des noyaux, pas des "verts".

Autres Points/Pensées:

• Hadoop est couramment utilisé pour les problèmes de cette nature, mais cela doit être en temps réel par rapport à l'extraction de données hors ligne stéréotypée.
• Les requêtes API prennent part de 200ms à 2 secondes en moyenne
• Il n'y a pas d'état partagé entre les demandes
• La 3ème partie en question est capable de desservir plus de demandes que nous pouvons éventuellement le feu (fournisseur de paiements).

Answer 1

Ce n'est pas évident pour moi que vous ayez besoin de plus de ressources (machines plus grandes ou plus de machines). Si vous parlez d'au plus 10 millions de requêtes par jour, en prenant au maximum 2 secondes chacune, cela signifie:

• ~ 110 requêtes par seconde. Ce n'est pas si rapide. Les demandes sont-elles particulièrement importantes? Ou y a-t-il de grandes rafales? Effectuez-vous un traitement lourd en plus de l'envoi vers l'API tierce? Vous ne m'avez donné aucune information jusqu'ici qui me laisse croire qu'il n'est pas possible d'exécuter votre service entier sur un seul noyau. (Appelez-le trois des plus petites machines possibles si vous voulez avoir une redondance n + 2.)
• en moyenne, ~ 220 demandes actives. Encore une fois, cela ne semble pas poser de problème pour une seule machine, même avec un modèle (poolé) de threads par requête. Pourquoi ne pas simplement augmenter la taille de votre piscine et l'appeler un jour? Sont-ils vraiment éclatants? (Et avez-vous des exigences de temps de latence/fiabilité très serrées?) Ont-ils besoin d'une grande quantité de RAM lorsqu'ils sont actifs?

Pourriez-vous donner plus d'informations sur pourquoi vous pensez que vous devez faire ce choix?

Answer 2

Plutôt que d'utiliser un grand nombre de threads, vous pouvez obtenir de meilleurs résultats avec les E/S pilotées par événement en utilisant node.js avec les avertissements que cela peut signifier une réécriture importante et le fait que node.js est assez jeune.

Cette SO article peut être d'intérêt.