Libevent 2.0.1 alpha, la nouvelle version de libevent

Posté par . Modéré par patrick_g.
Tags :
2
20
avr.
2009
Internet
Libevent se propose d'abstraire les différents mécanismes de multiplexage d'entrées/sorties tels que epoll, kqueue et event ports. Elle offre une interface simple pour des callbacks sur les entrées/sorties ainsi que sur des minuteries. La nouvelle version de libevent, en cours de développement, vise la compatibilité binaire avec la précédente version, dont la dernière en date est la version 1.4.10.

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.
  • # Record battu

    Posté par (page perso) . Évalué à 2.

    Là, c'est l'info la plus technique que j'ai jamais vu dans une depêche.... Patrick G. peut aller se coucher avec ses explications des améliorations du noyau.
    Allez, j'essaye de comprendre : cette librairie va remplacer Apache et Named?

    ⚓ À g'Auch TOUTE! http://agauch.online.fr

    • [^] # Re: Record battu

      Posté par (page perso) . Évalué à 4.

      Il l'a modérée quand même :D

      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 (page perso) . Évalué à 2.

        Heeeuuu... apache est sur une architecture threadée il me semble.

        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 . Évalué à 3.

          Heeeuuu... apache est sur une architecture threadée il me semble.

          Ç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 . Évalué à 3.

        select/poll/epoll/kqueue et compagnie permettent de savoir si un file descriptor (c'est à dire socket, fichier, entrée standard, etc [1]) est lisible où écrivable. De base aucun de ces appels systèmes n'appel de callbacks, c'est le boulot de libevent de retrouver quelles fonctions appeler.

        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 à ceux qui les ont postés. Nous n'en sommes pas responsables.