Bonjour, je souhaiterais conna=EEtre la diff=E9rence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
=E7a vaut aussi pour tout les serveurs). J'ai du mal =E0 trouver une doc
simple sur le net.
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l'OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres : http://www.acme.com/software/thttpd/benchmarks.html
Et lighttpd il me semble...
-- William Dodé - http://flibuste.net
On 29-08-2006, rejoc wrote:
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les
problématiques de perfs des applis web au sens large, me semble
intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de
l'attente de la réponse à la requête ( http, imap pop ou autre ) à un
réacteur ( un programme en boucle optimisé selon l'architecture ). Au
retour de la requête le réacteur déclenche un call back pour traiter la
réponse. Du coup il n'y a pas de threads en attente de réponse ( un
thread c'est peut être peu de choses mais si il y a 10000 connections
simultanés comme dans le cas d'un serveur web très chargé ou de gros
serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/).
Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut
pour travailler de manière asynchrone (c'est le "mode" de base de l'OS
(le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads
ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres :
http://www.acme.com/software/thttpd/benchmarks.html
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l'OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres : http://www.acme.com/software/thttpd/benchmarks.html
Et lighttpd il me semble...
-- William Dodé - http://flibuste.net
rejoc
On 29-08-2006, rejoc wrote:
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l'OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres : http://www.acme.com/software/thttpd/benchmarks.html
Et lighttpd il me semble...
Les courbes de perf sont sans appel...
On 29-08-2006, rejoc wrote:
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les
problématiques de perfs des applis web au sens large, me semble
intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de
l'attente de la réponse à la requête ( http, imap pop ou autre ) à un
réacteur ( un programme en boucle optimisé selon l'architecture ). Au
retour de la requête le réacteur déclenche un call back pour traiter la
réponse. Du coup il n'y a pas de threads en attente de réponse ( un
thread c'est peut être peu de choses mais si il y a 10000 connections
simultanés comme dans le cas d'un serveur web très chargé ou de gros
serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/).
Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut
pour travailler de manière asynchrone (c'est le "mode" de base de l'OS
(le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads
ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres :
http://www.acme.com/software/thttpd/benchmarks.html
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l'OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres : http://www.acme.com/software/thttpd/benchmarks.html
Et lighttpd il me semble...
Les courbes de perf sont sans appel...
evaisse
hum,j'utilise actuellement lighttpd. Performant surtout par rapport à sa consommation. au passage, les benchs du site de lighttpd : http://www.lighttpd.net/benchmark/
On 29-08-2006, rejoc wrote:
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour tr aiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connectio ns simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l' OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les thr eads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres : http://www.acme.com/software/thttpd/benchmarks.html
Et lighttpd il me semble...
Les courbes de perf sont sans appel...
hum,j'utilise actuellement lighttpd. Performant surtout par rapport à
sa consommation.
au passage, les benchs du site de lighttpd :
http://www.lighttpd.net/benchmark/
On 29-08-2006, rejoc wrote:
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les
problématiques de perfs des applis web au sens large, me semble
intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de
l'attente de la réponse à la requête ( http, imap pop ou autre ) à un
réacteur ( un programme en boucle optimisé selon l'architecture ). Au
retour de la requête le réacteur déclenche un call back pour tr aiter la
réponse. Du coup il n'y a pas de threads en attente de réponse ( un
thread c'est peut être peu de choses mais si il y a 10000 connectio ns
simultanés comme dans le cas d'un serveur web très chargé ou de gros
serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/).
Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut
pour travailler de manière asynchrone (c'est le "mode" de base de l' OS
(le mécanisme s'appelle les AST (Asynchronous System Trap)), les thr eads
ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres :
http://www.acme.com/software/thttpd/benchmarks.html
hum,j'utilise actuellement lighttpd. Performant surtout par rapport à sa consommation. au passage, les benchs du site de lighttpd : http://www.lighttpd.net/benchmark/
On 29-08-2006, rejoc wrote:
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour tr aiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connectio ns simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l' OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les thr eads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
En fait y en a pas mal d'autres : http://www.acme.com/software/thttpd/benchmarks.html
Bon ben j'ai trouvé ce qui pourrais être une bonne conclusion; Une doc en français, claire et consice sur les scchéma de conception de serveur web : http://www.run.montefiore.ulg.ac.be/~martin/resources/server-programming.ht ml
Bon ben j'ai trouvé ce qui pourrais être une bonne conclusion;
Une doc en français, claire et consice sur les scchéma de conception
de serveur web :
http://www.run.montefiore.ulg.ac.be/~martin/resources/server-programming.ht ml
Bon ben j'ai trouvé ce qui pourrais être une bonne conclusion; Une doc en français, claire et consice sur les scchéma de conception de serveur web : http://www.run.montefiore.ulg.ac.be/~martin/resources/server-programming.ht ml
