Tests comparatifs des solutions
La machine de test est un PIII 600MHz, 128 Mb RAM, carte réseau eepro100 connectée à un switch fast ethernet 100Mbps. Le noyau est un 2.4.6 sur une RedHat 6.2 et la version de la librairie des coroutines est 1.1.0-pre2. J'ai utilisé un double PIII 1GHz, 256 Mb RAM et une eepro100 pour la machine http cliente. Enfin, un double PIII 900 MHz, 256 Mb RAM et une eepro100 a été utilisée comme machine deadconn(tm). Pour que le client http (httperf) puisse réaliser un grand nombre de connexion très rapidement afin de réquisitionner tous l'espace alloué au descripteurs de fichiers (modifié à 8000), j'ai utilisé la commande suivante :
--think-timeout 5 --timeout 5 --num-calls 2500 --num-conns 100 --hog --rate 100
Vous vouvez télécharger httperf ici :
http://www.hpl.hp.com/personal/David_Mosberger/httperf.html
Le test montre que /dev/epoll est à peut prèt 10-12% plus rapide que le RT signals one-sig mais aussi que pour /dev/epoll et les deux RT signals conservent leurs capacités de réponse malgré l'accroissement des connexions mortes sur le serveur. Le RT-one-sig est un peu plus rapide que le simple RT signal.
Les deux tests à respectivement 512 and 1024 de longueur de trame montrent
que /dev/epoll, RT signals and RT one-sig ont un comportement à peu près
identique ( voir graphiques ci-dessus). C'est due à la saturation du
réseau éthernet ( 100Mbps ) qui a eu lieu durant ces tests.
Ce test montre que /dev/epoll, RT signals and RT one-sig ont un comportement
à peu près identique sous le chargement des connection mortes,
avec /dev/epoll qui est 15% plus rapide que RT one-sig et RT one-sig étant
10-15% plus rapide que le simple RT signals.
Conclusion
Ces chiffres démontrent que le très récent /dev/epoll
augmente les performances du serveur aussi bien du point de vue du temps de
réponse qu'au point de vue de la charge du CPU ( meilleure valeur pour
le facteur de charge CPU ). Le temps de réponse de /dev/epoll est completement
indépendant du nombre de connexions par rapport à la méthode
standard poll( ) et de /dev/poll qui semblent souffrir du chargement des connexions
mortes.