Les nouveautés en bref :
- Utilisation du edge triggering ;
- Utilisation des appels système sans copie (zero copy) comme sendfile ou le plus récent splice ;
- Les tampons ne sont plus nécessairement un bloc contigu mais peuvent être constitué d'une liste chaînée de blocs contigus ;
- Support des processus légers ;
Deux sous-systèmes sont particulièrement intéressants :
- evhttp.h permet de créer des serveurs Web ;
- evdns.h permet de créer des serveurs et des clients DNS asynchrones
À venir :
- Création d'un filtre OpenSSL ;
- Support d'I/O Completion Ports (IOCP) pour Windows.
NdM : la première version de la série 2.x est sortie il y a 3 jours (version 2.0.1a). Libevent est distribué sous licence BSD et est utilisé par de multiples autres logiciels : Honeyd, Memcached, ScanSSH, Tor, Systrace, etc.
Aller plus loin
- Page principale de libevent (41 clics)
- What's New In Libevent 2.0 (8 clics)
# Record battu
Posté par ʭ ☯ . Évalué à 2.
Allez, j'essaye de comprendre : cette librairie va remplacer Apache et Named?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Record battu
Posté par Dup (site web personnel) . Évalué à 4.
Libevent se propose d'abstraire les différentes mécanismes
Non ca ne remplace ni apache ni named (bind est son nom). Les APIs kqueue, epoll permettent d'appeler une fonction lorsqu'un changement est détecté sur un descripteur de fichier (arrivée de données, ou timeout expiré et que sais-je, suis pas expert :p) et assure de très bonnes performances lors de montée en charge en comparaison à un select (suffit de cliquer sur les liens).
Par contre il y a fort à parier qu'apache se servent se kqueue ou epoll selon l'architecture (kqeue = bsd, epoll = linux, select = POSIX ??, toujours si ma mémoire ne défaille pas), la il s'agit d'une bibliothèque d'abstraction de ces APIs.
Bon n'hésiter pas à me lyncher pour toute bétise se glissant dans mon commentaire.
[^] # Re: Record battu
Posté par jve (site web personnel) . Évalué à 2.
Les fonctions de type select, poll, epoll et kqueue s'occupent de monitorer des ensembles de sockets (disons, par exemple, plusieurs milliers de connexions réseaux) et de ne renvoyer au programme que celles qui ont des données a traiter.
En pratique, plutot que d'avoir un thread par socket et de faire de l'attente active, ce qui plombe les performances, on a un processus qui gére les 35 000 sockets et ne renvoie que ceux sur lesquels il y a de l'activité.
J'avais écris un billet sur le sujet, ca vaut ce que ca vaut...
http://jve.linuxwall.info/blog/index.php?post/2008/12/04/70-(...)
[^] # Re: Record battu
Posté par Antoine . Évalué à 3.
Ça ne l'empêche pas forcément d'utiliser select & friends.
libevent permet certes de créer des serveurs mono-threadés à partir d'une boucle événementielle, mais il n'est pas forcément idiot de déléguer certaines requêtes à des threads dédiés. C'est le cas en particulier s'il y a un mix entre des requêtes courtes et des requêtes longues à traiter avec des traitements synchrones qui ne rendent pas la main à la boucle d'événements. Dans un serveur Web, on n'a pas envie de bloquer la livraison des fichiers statiques pendant qu'une page dynamique (PHP, etc.) se calcule.
Un article connu sur le sujet :
http://www.kegel.com/c10k.html
[^] # Re: Record battu
Posté par vg . Évalué à 3.
Une des grandes nouvauté de la version 2.0 c'est le support du edge-triggering : l'ancien mécanisme (level-triggering) notifie l'utilisateur quand des données sont en attente dans les buffers du noyau, c'est à dire que tant qu'il y a des données à lire on est notifié.
L'edge-triggering par contre ne notifie pas l'utilisateur quand une socket est lisible/écrivable mais quand elle _devient_ lisible/ecrivable, c'est à dire que tant qu'on a pas entièrement vidé ou rempli les buffer du noyau on ne recoit plus d'événements (avec des IO non bloquants, on sait qu'on a vidé/rempli le buffer du noyau quand read/write échouent avec errno == EAGAIN).
L'avantage du edge-triggering c'est qu'il y a beaucoup moins d'appels systèmes à faire, notamment pour l'écriture. Avec le level triggering il fallait, à chaque fois qu'on a un truc à écrire, demander à epoll/kqueue si la socket est écrivable (donc un appel système pour ajouter la demande d'écriture, un appel système pour attendre la réponse du noyau, et enfin un appel système pour retirer la demande d'écriture).
Là on se contente d'ajouter la demande d'écriture au début, et tant que write ne renvoit pas d'erreur, on écris directement, sinon on attend que la socket redeviennent écrivable.
La version 2.0 est vraiment alléchante, la zero-copy est très importante aussi, en gros éviter au maximum les copies de buffers. sendfile() permet par exemple d'écrire directement un fichier dans une socket sans passer par un buffer temporaire dans le programme. vmsplice() à aussi une option très intéressante qui permet de carrément 'donner' une page mémoire au kernel pour qu'il l'écrive dans une socket plutôt que de la recopier.
C'est du bon, la version stable de libevent m'avait un peu décu par rapport à la plus récente libev [2] (trop grosse, des bugs un peu bête sur epoll, etc), mais je teste la version 2.0 dès que possible :)
[1]: À noter que epoll ne gêre pas les fichiers réguliers, ceux-ci sont censé pouvoir être lu et écrit sans bloquer.
[2]: http://software.schmorp.de/pkg/libev.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.