Quelques questions fondamentales mais importantes sur le développement Web?

Question

J'ai développé des applications basées sur le web jusqu'à présent à l'aide de PHP, Python et Java. Mais certains fondamentaux, mais des questions très importantes sont encore au-delà de mes connaissances, j'ai donc fait ce post pour obtenir de l'aide et éclaircissements de vous les gars.

Dis-je utiliser certains langage de programmation comme mon backend langage(PHP/Python/.Net/Java, etc), et je déployer mon application avec un serveur web(apache/lighttpd/nginx/IIS, etc). Et supposons qu'à l'instant T, l'une de mes page a obtenu 100 demandes simultanées de différents utilisateurs. Donc mes questions sont:

1. Comment est-ce que mon serveur web poignée de ces 100 demandes simultanées? Va serveur web de générer un processus/thread pour chaque demande? (si oui, un processus ou un thread?)
2. Comment l'interprète du backend langue? Comment est-il gérer la demande et de générer du html propre? Sera l'interprète de générer un processus ou un thread pour chaque demande?(si oui, un processus ou un thread?)
3. Si l'interprète de générer un processus ou un thread pour chaque demande, comment au sujet de ces processus(les threads)? Vont-ils partager du code de l'espace? Vont-ils communiquer les uns avec les autres? Comment gérer les variables globales dans le backend codes? Ou ils sont indépendants les processus(les threads)? Combien de temps est la durée du processus/thread? Ils seront détruits lorsque la demande est traitée et que la réponse est renvoyée?
4. Supposons que le serveur web ne peuvent prendre en charge 100 demandes simultanées, mais maintenant il a obtenu 1000 demandes simultanées. Comment gérer une telle situation? Est-il gérer comme une file d'attente et le traitement de la demande lorsque le serveur est disponible? Ou d'autres approches?
5. J'ai lu quelques articles sur la Comète ces jours-ci. Et je l'ai trouvé long de la connexion peut être un bon moyen de traiter en temps réel multi-utilisateurs de cas d'utilisation. Alors, comment au sujet de longue connexion? Est-ce une caractéristique de certains serveurs web ou il est disponible pour tous les serveurs web? Connexion longue nécessitera un long-existant interprète processus?

Merci à tous. Ces questions me gênait beaucoup. Donc j'espère que vous pouvez aider. Une réponse plus détaillée sera grandement apprécié. Et s'il vous plaît ajouter des références.

Ce qui concerne.

---

EDIT: Récemment, j'ai lu quelques articles à propos de CGI, fastcgi, ce qui me fait connaître l'approche de fastcgi devrait être une approche typique pour hanlde demande.

le protocole de multiplexes une seule connexion de transport entre plusieurs requêtes FastCGI. Cela prend en charge les applications qui sont en mesure de traiter les demandes simultanées à l'aide de l'événement ou du multi-thread techniques de programmation.

Cité de fastcgi spec, qui mentionne la connexion qui peut gérer plusieurs demandes, et peut être mis en œuvre en multi-thread tech. Je me demandais cette connexion peut être traitée en tant que processus et il peut générer plusieurs threads pour chaque demande. Si cela est vrai, je deviens plus confus sur la façon de gérer la ressource partagée dans chaque thread?

P. S merci à Thomas pour les conseils de spiting le poteau à plusieurs postes, mais je pense que les questions sont liées et il est préférable de les regrouper.

Merci à S. Lott pour votre réponse, mais quelques réponses à chaque question sont trop brèves ou non couverte.

Merci à tout le monde de réponse, qui me rend plus proche de la vérité.

Une réponse détaillée sera grandement apprécié!

Answer 1

Comment est-ce que mon serveur web poignée de ces 100 demandes simultanées? Ne serveur web va générer un processus/thread pour chaque demande? (si oui, un processus ou un thread?)

Il varie. Apache a les threads et les processus de traitement des demandes. Apache démarre plusieurs processus simultanés, chacun de qui peut exécuter n'importe quel nombre de threads simultanés. Vous devez configurer Apache pour contrôler la façon dont cela se joue pour chaque demande.

Comment l'interprète du backend langue? Comment est-il gérer la demande et de générer du html propre? Sera l'interprète de générer un processus ou un thread pour chaque demande?(si oui, un processus ou un thread?)

Cela varie en fonction de votre configuration d'Apache et de votre langue. Pour Python, une approche classique consiste à avoir démon processus en cours d'exécution en arrière-plan. Chaque processus Apache possède un processus de démon. Cela se fait avec la mod_wsgi module. Il peut être configuré de plusieurs façons différentes.

Si l'interprète de générer un processus ou un thread pour chaque demande, comment au sujet de ces processus(les threads)? Vont-ils partager du code de l'espace? Vont-ils communiquer les uns avec les autres? Comment gérer les variables globales dans le backend codes? Ou ils sont indépendants les processus(les threads)? Combien de temps est la durée du processus/thread? Ils seront détruits lorsque la demande est traitée et que la réponse est renvoyée?

Les Threads partagent le même code. Par définition.

Les processus partagent le même code parce qu'Apache fonctionne.

Ils ne sont pas intentionnellement -- -- communiquer les uns avec les autres. Votre code ne dispose pas d'un moyen facile de déterminer ce qui se passe. C'est par la conception. Vous ne pouvez pas dire le processus qui vous êtes en cours d'exécution, et ne peux pas dire ce que les autres threads sont en cours d'exécution dans cet espace de processus.

Les processus sont de longue durée. Ils ne sont pas (et ne doivent) être créés dynamiquement. Vous configurer Apache pour fourche simultanées de plusieurs copies de lui-même quand il commence à éviter la surcharge du processus de création.

Création de Thread a beaucoup moins de frais généraux. Comment les Apaches gère les threads en interne n'a pas beaucoup d'importance. Vous pouvez, cependant, pensez à Apache que le démarrage d'un thread par demande.

Supposons que le serveur web ne peuvent prendre en charge 100 demandes simultanées, mais maintenant il a obtenu 1000 demandes simultanées. Comment gérer une telle situation? Est-il gérer comme une file d'attente et le traitement de la demande lorsque le serveur est disponible? Ou d'autres approches?

C'est la "scalability" question. En bref: comment les performances se dégradent à mesure que la charge augmente. La réponse générale est que le serveur devient plus lent. Pour certains du niveau de charge (disons 100 demandes simultanées) il y a assez de processus qu'ils ont tout géré de manière respectable rapide. À un certain niveau de charge (disons 101 demandes simultanées), il commence à se ralentir. À un autre niveau de charge (qui sait combien de demandes) il est tellement lent que vous n'êtes pas satisfait de la vitesse.

Il y a une file d'attente interne (dans le cadre de la voie TCP/IP fonctionne, en général), mais il n'y a pas de gouverneur, ce qui limite la charge de travail de 100 demandes simultanées. Si vous obtenez plus de demandes, plus de threads sont créés (pas plus de processus) et que les choses fonctionnent plus lentement.

Answer 2

Pour commencer, exigeant des réponses détaillées à toutes vos points est un peu beaucoup, à mon humble avis.

De toute façon, quelques réponses à vos questions:

#1

Il dépend de l'architecture du serveur. Apache est un multi-processus, et, en option, multi-thread serveur. Il y a un processus maître qui écoute sur le port de réseau et gère un pool de processus de travail (dans le cas de "l'ouvrier" mpm chaque processus de travail a plusieurs threads). Lorsqu'une demande arrive, il est transmis à l'un de l'inactivité des travailleurs. Le maître gère la taille du pool de travail par le lancement et arrêt des travailleurs en fonction de la charge et les paramètres de configuration.

Maintenant, lighthttpd et nginx sont différents, ils sont d'événement soi-disant architectures basées sur les, où plusieurs connexions réseau sont multiplexées sur un ou plusieurs processus de travail/threads en utilisant le support de l'OS pour l'événement de multiplexage tels que le classique select()/poll() dans POSIX, ou plus évolutif mais malheureusement OS-mécanismes spécifiques tels que epoll sous Linux. L'avantage, c'est que chaque nouvelle connexion réseau a besoin seulement peut-être de quelques centaines d'octets de la mémoire, permettant à ces serveurs afin de garder ouvertes des dizaines de milliers de connexions, ce qui serait généralement prohibitif pour une demande par processus/thread de l'architecture tels que apache. Toutefois, ces événements basés sur des serveurs pouvez toujours utiliser plusieurs threads ou processus afin d'utiliser plusieurs cœurs de PROCESSEUR, et aussi afin d'exécuter un système de blocage des appels en parallèle comme normal de fichiers POSIX I/O.

Pour plus d'informations, voir un peu daté C10k page par Dan Kegel.

#2

Encore une fois, ça dépend. Pour classique CGI, un nouveau processus est lancé pour chaque demande. Pour mod_php ou mod_python avec apache, l'interprète est intégré dans les processus apache, et par conséquent, il n'est pas nécessaire de lancer un nouveau processus ou thread. Cependant, cela signifie également que chaque processus apache nécessite beaucoup de mémoire, et en combinaison avec les questions que j'ai expliqué ci-dessus pour le #1, les limites de l'évolutivité.

Afin d'éviter cela, il est possible d'avoir un pool distinct de poids lourd processus en cours d'exécution de l'interprète, et l'interface web, les serveurs proxy les backends lors de contenu dynamique doit être généré. C'est essentiellement l'approche adoptée par FastCGI et mod_wsgi (bien qu'ils utilisent des protocoles personnalisés et pas HTTP donc peut-être que techniquement ce n'est pas de proxy). C'est aussi généralement l'approche choisie lors de l'utilisation de l'événement à base de serveurs, comme le code pour générer le contenu dynamique est rarement ré-entrant dont elle aurait besoin pour être en ordre pour fonctionner correctement dans un événement en fonction de l'environnement. En va de même pour le multi-thread approches ainsi, si le contenu dynamique de code n'est pas thread-safe; on peut avoir, dire, frontend serveur apache avec le filetage de mpm worker l'utilisation de proxy pour backend serveurs apache exécution de code PHP avec le single-threaded mpm prefork.

#3

Selon le niveau dans lequel vous vous posez la question, ils vont partager de la mémoire par le système d'exploitation mécanisme de mise en cache, oui. Mais en général, à partir d'un programmateur de point de vue, ils sont indépendants. Notez que cette indépendance n'est pas en soi une mauvaise chose, car elle permet à la simple mise à l'échelle horizontale pour plusieurs machines. Mais hélas, certains de communication est souvent nécessaire. Une approche simple consiste à communiquer par le biais de la base de données, en supposant que l'on est nécessaire pour d'autres raisons, comme à son habitude. Une autre approche consiste à utiliser certains dédié à mémoire distribuée système de mise en cache comme memcached.

#4

Dépend. Ils pourraient être mis en file d'attente, ou le serveur peut répondre de code d'erreur, tels que HTTP 503, ou le serveur ne peut simplement refuser la connexion à la première place. Généralement, tous les ci-dessus peuvent se produire en fonction de la façon dont chargé le serveur.

#5

La viabilité de cette approche dépend de l'architecture du serveur (voir ma réponse #1). Pour un événement basé sur serveur, en gardant les connexions ouvertes est pas un gros problème, mais pour apache, il est certainement en raison de la grande quantité de mémoire requise pour chaque connexion. Et oui, cela nécessite certainement une longue interprète processus, mais comme décrit ci-dessus, sauf pour le classique de la CGI, c'est à peu près acquis.

Answer 3

Un serveur Web est un environnement multi-thread; en outre à l'aide de l'application d'étendue variables, une demande de l'utilisateur n'interagit pas avec d'autres threads.

Donc:

1. Oui, un nouveau sujet sera créé pour chaque utilisateur
2. Oui, HTML seront traités pour chaque demande
3. Vous aurez besoin d'utiliser l'application étendue des variables
4. Si vous obtenez plus de demandes que vous pouvez faire face, ils seront mis sur la file d'attente. Si elles ont été servis avant configuré délai, l'utilisateur va obtenir sa réponse, ou un "serveur occupé" comme erreur.
5. La comète n'est pas spécifique pour serveur/langue. Vous pouvez atteindre le même résultat par quering votre serveur toutes les n secondes, sans traiter d'autres mauvaises threads questions.

Answer 4

Parce que l'isolation des processus est quelque chose que vous n'avez pas toujours le contrôle ou les connaissances, ce que j'ai appris jusqu'à présent, c'est que je doit écrire le code qui s'appuie sur les threads et les "contextes" pour stocker des données qui permettraient de façon "classique" être stockées en tant que données statiques. Mais même cela peut changer dans un avenir proche avec l'avènement de Continuations.