2012-03-05 2 views
0

Lors du déploiement d'applications Web, une approche courante consiste à implémenter la logique applicative actuelle sous la forme d'une série de services et à les exposer via HTTP, puis à mettre des frontaux entre les services et les utilisateurs. Généralement, ces interfaces prennent en charge des éléments tels que le protocole SSL, les données de session, l'équilibrage de charge, les demandes de routage, éventuellement la mise en cache, etc.Quelle est l'importance des connexions LAN locales LAN aux API sous-jacentes des infrastructures Web?

AFAIK, cela signifie généralement que chaque fois qu'une nouvelle demande arrive, une ou plusieurs nouvelles demandes doivent être adressées à un ou plusieurs des backends: chacun avec sa poignée de main TCP, les frais généraux HTTP, etc.

Ces connexions supplémentaires n'at-elles pas ajouté une latence mesurable et/ou un impact sur les performances? Si oui, quelles sont les techniques courantes pour obtenir les meilleures performances de ce type de déploiement?

Répondre

0

La latence sur une connexion locale sera minime - un chiffre en millisecondes probablement. Il y aura un certain temps d'occupation pour les sessions HTTP supplémentaires, mais il sera ensuite réparti entre différentes applications. L'avantage de l'approche que vous décrivez est de répartir la charge entre différentes applications, ce qui vous permet d'avoir beaucoup de bits frontaux comme SSL et de réduire le nombre d'applications backend qui gèrent plus de sessions. Et vous pouvez choisir et mélanger les applications dont vous avez besoin.

Une seule application monolithique sera probablement un peu plus rapide jusqu'à ce qu'elle soit à court de capacité, ce qui vous posera un problème, car il est difficile de l'augmenter.