salut,
> Ayant discuté avec la personne appropriée, tu peux utiliser le runtime
> Air en CLI a condition de demander une distribution spéciale à Adobe
> où les conditions d'utilisations seront pré-acceptées.
> Ensuite, toute la démarche est la même qu'avec le runtime 1.0 décrit
> dans la page du labs dédiée a linux.
>
intéressant, je savais pas ca
reste que, meme en connaissant cela, je referrais pareil redtamarin :p
- open source
- pas de conditions d'utilisations
- extensions a souhait
> J'avais fait aussi des tests avec le ServerSocket ; je doutais (à
> l'époque) sur la possibilité du serveur a monter en charge. Cette
> nouvelle solution parait être un peu mieux
>
> J'attends de voir exemples et perfs :)
c'est ce qui manque en effet
theoriquement ca devrait tenir la charge, mais je n'ai jamais testé en
vrai prod
donc je ne peux pas honnetement dire que "oui ca tiens la charge", il
faut tester
l'autre avantage, c est que l'implementation de avmplus.Socket
bah désolé pour Adobe mais je pense qu'elle est bien mieux que celle
de flash.net.Socket/SocketServer
c'est des petites différences ici et là mais au final quand on les
accumule ca pese son poids
* la gestion des buffer de socket
completement ignoré par Flash/AIR
on peut choisir dans redtamarin
* les events
on pourrait dire que le defaut de redtamarin
c'est de ne pas gerer les events en natif
mais a mon avis c'estg ce qui peut faire la différence
pour un server performant
pour donner plus de details sur l'implementation des sockets dans
redtamarin
au depart je ne voullais pas faire de multi-threading ou d'events
car justement je n'avais pas la partie C++ et/ou la logique d'events
qu'il y a dans le flash player
le fait que je voullais garder un code source cross platform
m'a aussi interdit d'utiliser qlqch comme fork() (tres souvent
utiliser
pour du server de socket avec plusieurs connections mais pas dispo
sous Windows)
apres ca j'avais donc le choix entre 2 techniques:
select() ou poll()
j'ai exclut poll() car c'est en soit un peu comme des events et je
voullais garder les choses simple
donc il ne restait plus que select()
donc en cherchant du coté des sockets blocking et comment faire du
multiplexing avec select()
et bien on découvre des choses intéressantes
* primo le gros default d'utiliser select() avec des socket blocking
c'est que chaque request client bloque le client suivant
cad des qu'on utilise accept(), recv() send() ca bloque sur 1
connection
* bah alors pourquoi pas utiliser select() avec des non-blocking
socket ?
parce que là en non-blocking le loop pour gerer la connection des
sockets
va utiliser proche de 100% du CPU, donc on oublit le non-blocking
* mais select() par rapport a fork()
et bien fork() cree un nouveau process pour chaque connection
et ca, ca bouffe plein de ressources (Memoire, CPU, etc.)
c'est un peu comme broswer le web dans les années 90
cad lancer un navigateur par page web
* utiliser du multi-thread c'est en soit un peu mieux que fork()
car ca utilise un peu moins de ressources mais ca bouffe qd
meme pas mal de ressources
de plus il y a des limitations, sous Windows par ex
on peut creer de 1000 a 2000 threads par process,
sous Linux/OSX il y a plus ou moins les meme limites
et en plus de cela il y a un gros probleme de "context switching"
cad passer d'un thread a un autre thread
bon j;essaye de resumer,
pour chaque process le CPU a une limite de gestion des IO (input/
output)
mais si en plus on utilise plusieurs threads, chaques threads
utilisés
reduit encore plus le temps que le CPU peut passer a gerer l'IO
bref, tout ca, ca peut limiter le nombre de connections
concurrentes a 500,
pas terrible donc
* mais disons qu'on utilise select() qd meme, là on découvre le 2nd
defaut
select() est limité par le nombre de file descriptor de FD_SETSIZE
sous Windows ca se reduit a 64 (OSX et Ubuntu c'est 1024)
cad que meme si select() pouvait gerer les connections en non-
blocking
on serait limité a 64 (ou 1024) connections simultanées
* mais il y a encore un 3eme probleme avec select()
select() utilise un timeout
so celui-ci est NULL, select() est blocking
et non-NULL select() attends jusqu'a a la fin du timeout
bref , c est un beau bordel :)
mais en cherchant et cherchant encore on trouve des solutions
donc voici le detail de ce qui se passe dans l'implementation de
redtamarin
on fait du "Synchronous I/O multiplexing"
les fonctions accept(), recv(), send() sont blocking
par contre select() lui est non-blocking car on utilise un timeout de
0sec,
en fait juste ca c'est LE truc qui permet de faire du socket server :p
et donc cela marche comme ca:
- on un loop infini qui utilise select() non-blocking pour savoir si
il y a des donnees sur les sockets
- quand on a des donnees, on utilise une des fonctions blocking
accept(), recv(), send()
- cad que on est en mode "blocking" que pendant le traitement des
donnees sur UNE socket
- a la fin du loop on ajoute un timeout avec la fonction blocking
sleep()
de plus, pour la limitation de FD_SETSIZE, qui limite donc a maximum
64 (ou 1024) sockets concurrentes,
et bien on a overrider FD_SETSIZE dans redtamarin pour le passer a
4096 sous Windows, OS X et Linux
et obtient donc ca
- un usage CPU qui est tres petit, de 0,1%, 1%, 15% etc. bref ca
scale bien
- un seul process, un seul thread donc, on peut utiliser le maximum
d'IO
- pas de partage de données entre plusieurs threads (ex: acces a une
DB ou ecrie un fichier en local)
- un plus grand nombre de socket concurrentes que si on utilisait
fork() ou les threads
- une simili gestion evenementielle, c'est pas de "vrai" events mais
ca marche presque pareil
- une logique un peu plus compliquée mais facilement gerable en AS3
donc pour l'instant il y a une limite arbitraire de 4096 pour "voir"
en fonction du serveur, de la RAM, du CPU etc.
en fonction du traitement des donnees (temps CPU passé par socket)
en fonction du timeout dans le loop
(j'utilise 1000ms (1sec) par defaut mais selon les applis on pourrait
mettre 20000ms (20sec) ou autre)
je pense qu'il est possible de vraiment gerer 4096 connections
concurrentes avec redtamarin
apres oui il faut des tests en grandeur nature pour etre vraiment sur
de ce qui se passe
zwetan
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes FCNG.
Pour envoyer un message à ce groupe, adressez un e-mail à [email protected].
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
[email protected].
Pour plus d'options, consultez la page de ce groupe :
http://groups.google.com/group/fcng?hl=fr
