Lorsque nous parlons de capacités d'une application Web, nous mentionnons souvent les demandes simultanées qu'il pourrait gérer.
comme mon Une autre question discutée, eThaNet Utilisez TDM (multiplexage de la division horaire) et aucun signal de 2 ne pouvait passer le long du fil simultanément. Donc, si le serveur Web est connecté au monde extérieur via une connexion Ethernet, il n'y aura littéralement aucune demande simultanée. Toutes les demandes vont venir l'une après l'autre.
Mais si le serveur Web est connecté au monde extérieur par quelque chose comme une carte réseau sans fil, je pense que les multiples signaux pourraient arriver simultanément à travers la vague électromagnétique. Ce n'est que dans cette situation, il existe de vraies demandes simultanées à parler.
suis-je juste sur cela?
merci.
3 Réponses :
Il est vrai que pas deux paquets ne peuvent arriver exactement au même moment (à moins que plusieurs cartes réseau ne soient utilisées par commentaire de Gabe). Cependant, la demande Web nécessite généralement un certain nombre de paquets. L'arrivée de ces packages est entrecoupée lorsque plusieurs demandes arrivent à proximité de la même heure (à l'aide d'un accès câblé ou sans fil). En outre, le traitement de ces demandes peut se chevaucher.
Ajouter Multi-threading (ou plusieurs processeurs / cœurs) à l'image et vous pouvez voir comment des opérations longues telles que la lecture d'une base de données (ce qui nécessite beaucoup d'attente pour une réponse) peut facilement se chevaucher même si l'individu Les paquets arrivent en série.
EDIT: Ajout de la note ci-dessus pour incorporer les commentaires de GABE.
J'imagine "les demandes simultanées" pour une application Web ne descend pas au niveau de lien. Il s'agit davantage de la transformation d'une demande de la demande et du nombre de demandes arrivent au cours de ce traitement.
Par exemple, si une demande prend en moyenne 2 secondes pour remplir (de la recevoir sur le serveur Web pour le traiter à travers l'application pour renvoyer la réponse), il pourrait être nécessaire de gérer beaucoup de demandes simultanées si elle obtient nombreuses demandes par seconde.
Les demandes doivent se chevaucher et être traitées simultanément, sinon la file d'attente des demandes se remplirait indéfiniment. Cela peut sembler être bon sens, mais pour de nombreuses applications Web, il s'agit d'une véritable préoccupation, car l'inondation de demandes peut déranger une ressource pour l'application, telle qu'une base de données. Ainsi, si l'application a des interactions de base de données médiocres (procédures trop complexes, une indexation / optimisation médiocre, une liaison lente vers une base de données partagée par de nombreuses autres applications, etc.), qui crée un goulot d'étranglement qui limite le nombre de demandes simultanées que l'application peut gérer. , même si l'application elle-même devrait être capable de les gérer.
.Imaging Un serveur HTTP à l'écoute du port 80, que se passe-t-il:
Un client se connecte au serveur pour demander une page; Il se connecte à partir d'une adresse IP d'origine, en utilisant un port local d'origine.
Le système d'exploitation (en réalité la pile de réseau) examine l'IP de destination de la demande entrante (puisque le serveur peut avoir plus d'une carte réseau et un port de destination (80) et vérifie que certaines applications sont enregistrées pour gérer les données à ce sujet. port (le serveur HTTP). La combinaison de 4 chiffres (origine IP, port d'origine, IP de destination, Port 80) identifie de manière unique une connexion. Si une telle connexion n'existe pas encore, une nouvelle est ajoutée à la table interne de la pile de réseau et une demande de connexion est transmise à la prise d'écoute du serveur HTTP. À partir de maintenant, la pile de réseau passe simplement sur des données pour cette connexion à l'application.
Plusieurs clients peuvent être envoyés à des demandes, pour chacun d'eux, ce qui précède se produit. Donc, du point de vue du réseau, tout se passe en série, car les données arrivent un paquet à la fois.
du point de vue du logiciel, le serveur HTTP écoute les demandes entrantes. Le nombre de demandes qu'il peut avoir la queue avant que les clients ne commencent à obtenir des erreurs déterminées par le programmeur en fonction de la capacité matérielle (il s'agit du premier bit de concurrence: il peut y avoir plusieurs demandes en attente d'être traitées). Pour chacun, il créera une nouvelle prise (aussi vite que possible afin de continuer à vider la file d'attente de demande) et de laisser le traitement réel de la demande soit effectué par une autre partie de l'application (différents threads). Ces routines de traitement (idéalement) consacrent la majeure partie de leur temps en attente de données pour arriver et réagir (idéalement) rapidement à elle.
Étant donné que le traitement des données est souvent plus rapide que l'E / S du réseau, le serveur peut gérer de nombreuses demandes lors du traitement du trafic réseau, même si le matériel comprend un seul processeur. Plusieurs processeurs augmentent cette capacité. Donc, du point de vue du logiciel, tout arrive simultanément.
Comment le traitement réel des données est implémenté est l'endroit où la clé de la performance réside (vous voulez que ce soit aussi efficace que possible). Plusieurs possibilités existent (des opérations de prise ASYNC telles que fournies par la classe Socket, threadpool, des threads uniques, les nouvelles fonctions parallèles de .NET 4).
Ceci est probablement plus compliqué que nécessaire. La question est une simple incompréhension de l'événement simultané.
Par "Demandes simultanées", nous ne voulons pas dire qu'ils sont sont arrivés simultanément , juste qu'ils sont traités simultanément. Bien que plusieurs interfaces réseau puissent permettre aux demandes d'arriver en même temps.