G-WAN consomme 15x moins de ressources qu'Apache

Par Frédéric Bordage  -  09/09/2009

 
ImprimerImprimer

TrustLeap - G-Wan - serveur d'application C - graphique benchmark performances

Les servlets C de G-Wan s'exécutent jusqu'à 400x plus vite que du code PHP ! Autant de Wh en moins.

Sur GreenIT.fr, nous n’abordons que rarement le domaine de l’efficacité énergétique d’un logiciel, c’est à dire sa capacité à délivrer plus de transactions, de pages web, ou de requêtes SQL par Wattheure (Wh). Essentiellement parce que les informations fiables et objectives manquent.

Pourtant, c’est un domaine particulièrement intéressant. Surtout quand on sait que les serveurs gaspillent environ 30 à 40% de l’électricité qu’ils consomment et que 70% des datacenters auront des problèmes techniques liés à leur consommation électrique à partir de 2011 (selon Gartner). Le bon vieux crédo de l’ère des mainframes - faire plus avec moins - redevient donc d’actualité.

C’est dans ce contexte que nous vous invitons à découvrir un nouveau serveur d’application gratuit, G-Wan. Il présente des caractéristiques techniques très intéressantes. Selon son éditeur, à configuration égale, il délivrerait 15x plus de pages web qu’Apache sur un processeur simple coeur et 3,7x plus de pages web sur un processeur multicoeurs. Dit autrement, G-Wan nécessite jusqu’à 15x moins d’énergie pour délivrer le même nombre de pages !

Forcément, pour obtenir de telles performances, les développeurs devront redevenir des développeurs et apprendre à coder en… C. Mais ils y gagneront en temps d’exécution. Les servlet C utilisés par G-Wan seraient ainsi 400x plus rapide que du code PHP, 200x que du code Python (utilisé par Google), et 8x plus rapide que Java. Détail ici.

Je sens déjà les nostalgiques des démos contraintes par 64 ko de RAM verser une larme de plaisir ;-).

Merci à Frederic de Baets pour l’alerte.

Partager sur Viadeo


Tags: , ,

Commentaires

[...] Editeur › G-WAN consomme 15x moins de ressources qu'Apache › GreenIT.fr www.greenit.fr/article/logiciels/g-wan-consomme-15x-moins-de-ressources-... – view page – cached TrustLeap - G-Wan - serveur d'application C - graphique benchmark performances — From the page [...]

Twitter Trackbacks for Editeur › G-WAN consomme 15x moins d (non vérifié) le 09/09/2009

Quand on regarde de plus près, on se rend compte que ça ne tourne que sous Windows, un OS énergivore qui nécessite beaucoup de ressources et qui ne tourne pas sur des architectures basses consommations.

Et aucune comparaison avec les autres framework écrits en C.

Despi (non vérifié) le 09/09/2009

@Despi : merci pour cette précision. Quels sont les autres frameworks écrits en C ?

admin le 09/09/2009

A propos des “autres frameworks écrits en C”:

Apache/PHP/Python et Microsoft IIS/ASP.Net sont écris en C… comme G-WAN.

Et les scripts ANSI C de G-WAN (qui s’exécutent à la volée, sans compilateur), sont 5 fois plus rapides qu’IIS 7.0 ASP.Net C#:

http://trustleap.fr/en_iis.html

ASP.Net

Enfin, G-WAN est portable (comme Apache), ce qui permettra d’en faire une version pour Linux, Solaris, etc.

Donc, mon petit ‘@Despi’ adoré, tu vois, il ne faut pas désespérer…

InLoveOfDespi (non vérifié) le 09/09/2009

Pour information le developpeur de G-Wan est en train de travailler sur la version Linux de G-Wan !!

Anodine75 (non vérifié) le 10/09/2009

@Anodyne75 : merci pour cette précision qui ravira certainement @Despi.

admin le 10/09/2009

Le tableau du language C dressé sur le site de G-Wan est pour le moins idyllique. S’il était facile de développer en C, et bien tout le monde développerait en C, non ? Les languages évolués qui lui ont succédé ont implémenté des mécanismes (gestion de la mémoire, objets) qui ont rendu le développement beaucoup plus rapide/facile mais qui ont pesé sur les performances. Le développeur a oublié le confort de ne pas avoir à déclarer la taille d’une chaine de caractères.

Performances et rationalisation des développements sont deux objectifs contradictoires étant toujours en lutte, même au sein d’un langage comme PHP où s’affrontent les fans des frameworks-qui-font-tout-mais-pèsent-lourd, et les tenants du PHP-hyper-optimisé-qui-reinvente-la-roue (note en passant, je suis très étonné par les performances de PHP dans ce bench, surtout lorsque l’on compare à Java). D’ailleurs, fort à parier que si G-Wan a du succès, on verra apparaitre des frameworks permettant de rendre le tout plus digeste, de ne pas avoir à coder des “sockets” SMTP pour envoyer un mail… au prix d’une perte de performances.

Peut-être faut-il alors rendre au C sa fonction première : un langage intermédiaire de pré-compilation. Peut-être faut-il envisager les environnements de production de façon différente : avec des serveurs d’application plus légers, et des scripts compilés (ex : un code PHP ou C++ ou ruby, traduit en C, puis compilé, tournant sur un serveur d’application léger comme G-Wan). Pas sur enfin qu’une fois rajoutés tous les mécanismes nécessaires à un site web moderne, on soit aussi légers (sécurisation, load balancing, sessions, rewriting d’urls, caches, …)

Le développeur Web sera très reconnaissant de ne pas avoir à retourner à l’assembleur 68000.

philippe (non vérifié) le 10/09/2009

Si on commence à rentrer dans cette réflexion (fort intéressante), il faudrait remarquer deux choses :
- l’inflation délirante de la complexité des pages web. Le pauvre HTML est poussé dans ses retranchements, les images envahissent les écrans, la moindre page pèse des dizaine ou des centaines de Ko… On pourrait aussi parler un peu de la tendance générale à l’embonpoint des fichiers et autres protocoles de com’ (merci le XML).
- l’utilisation presque systématique de serveurs d’app même pour des sites très largement statiques. Ca veut dire, par conséquent, du temps CPU consommé pour rien. Je me souviens, il y a une dizaine d’années, avoir travaillé sur une approche différente (nommée le “déport de charge”) : l’idée est d’avoir des pages non pas dynamiques, mais générées d’avance, à partir de données assez rarement mises à jour. Par exemple, si vous avez un catalogue produit, c’est une abberation que d’aller systématiquement créer une page catalogue en faisant un query SQL direct dans la base pour la renseigner. Il vaut mieux générer (cacher ?) les pages uniquement quand la base change.

Voilà donc, pas besoin d’être grand clerc… Une page HTML deux fois plus grosse, c’est deux fois plus de CPU (côté serveur et côté client) et de bande passante, donc, en gros, deux fois plus d’énergie consommée pour la traiter.

Zéro papier, certes, mais combien de CO2 ??

flet le 15/09/2009

@Flet : +1. Les sites à très gros volumes ont déjà une approche “écologique”. Pas pour préserver l’environnement, mais pour tenir la charge. Ils répartissent la charge en fonction du caractère statique ou dynamique du contenu et utilisent notamment des “filers” pour les contenus statiques. On peut facilement diviser par 3 ou 4 la charge CPU d’un site. Mais le coût de l’hébergement comparer au coût du développeur encourage le quick & dirty.

L’approche intelligente que tu suggères revient un peu à proposer à un développeur de re-découvrir le C ou l’assembleur… On y viendra dans quelques années quand le coût environnemental (CO2, déchets radioactifs, etc.) sera réellement pris en compte et fera grimper en flèche le coût final du kWh.

admin le 15/09/2009

En réponse à Philippe (qui mérite quand même une majuscule):

> S’il était facile de développer en C, et
> bien tout le monde développerait en C, non?

Excellente question, à laquelle une étude récente
a d’ailleurs répondu (par la positive):

http://www.theregister.co.uk/2009/01/21/open_source_projects_08/print.ht…

Sur 180.000 projets “open source”, 47% sont en C,
28% en Java et seulement 11% en PHP.

Par ailleurs:

Le C ANSI a 32/37 mots clefs et 146 fonctions.
PHP 5 a 73 mots clefs et 5.900 fonctions.

Lequel des deux est le plus facile à apprendre?

Mais, si le C est si magnifique, pourquoi apprend
-on le C# (plus gros, et 5x plus lent) à l’école?

Bonne question.

> Les languages évolués qui lui ont succédé ont
> implémenté des mécanismes (gestion de la mémoire,
> objets) qui ont rendu le développement beaucoup
> plus rapide/facile

Les memory pools de Java (et des autres) sont écrits
en C. Certains développeurs C sont capables de les
utiliser en C. G-WAN (le sujet de l’article) utilise
des memory pools et des buffers dynamiques pour éviter
la gestion des allocations de mémoire et les risques
d’erreur (ce qui importe pour un serveur).

Quand aux “objets”, d’une part l’OOP est née en ASM
(et se pratique très bien en C), et d’autre part, le
C++ (écrit en, heu, voyons voir… en C) n’est pas
connu pour faciliter ni accélérer les développements
(bien au contraire).

> Performances et rationalisation des développements
> sont deux objectifs contradictoires

Passons sur les erreurs de la nature et concentrons
-nous sur ce que certains décrivent comme un vrai
 langage:

C’est ce que le promoteur de C++, un certain Bjarne,
a essayé de faire croire pendant des années alors que
lui même avouait:

“Within C++, there is a much smaller and cleaner
language struggling to get out.”

D’autres, non moins compétents mais moins enclins à
l’auto-compassion, étaient plus directs:

“C++ is an insult to the human brain”
(Niklaus Wirth)

“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind”
(Alan Kay)

“There are only two things wrong with C++: The
initial concept and the implementation”
(Bertrand Meyer)

> si G-Wan a du succès, on verra apparaitre des
> frameworks permettant de rendre le tout plus digeste,
> de ne pas avoir à coder des “sockets” SMTP pour
> envoyer un mail

G-WAN a une fonction très compliquée pour faire cela
sans avoir recours aux sockets:

sendmail(server, from, to, title, text);

J'espère que les âmes sensibles ont tenu bon. Le choc
a dû être terrible pour ceux qui pensaient qu'un
"framework" était nécessaire pour envoyer un email.

> rendre au C sa fonction première : un langage
> intermédiaire de pré-compilation.

Dont le premier programme s'appelait... Unix.

Presque tous les autres systèmes d'exploitation,
et presque tous les langages de programmation
sont écrits en C.

Je me demande combien de programmeurs sont ainsi
dans l'ignorance qu'ils utilisent un simple outil
de pré-compilation.

Ils ne semblent pas en souffrir, c'est déjà ça.

> Peut-être faut-il envisager des serveurs d’application
> plus légers, et des scripts compilés (ex : un code
> PHP ou C++ ou ruby, traduit en C, puis compilé,
> tournant sur un serveur d’application léger comme G-Wan)

Les scripts en C de G-WAN n'ont pas besoin de compilateur,
mais tournent à la vitesse du code compilé (voir même plus
vite que le code natif de Windows), voir:

http://gwan.com/en_bench.html

Dans l'hypothèse (intéressante) de Philippe, il suffirait
d'un traducteur PHP vers C pour que PHP soit aussi rapide
que les scripts en C de G-WAN.

Google a un projet similaire (traduction de PHP en C),
cela doit donc répondre à un besoin réel.

> une fois rajoutés tous les mécanismes nécessaires
> à un site web moderne, on soit aussi légers
> (sécurisation, load balancing, sessions, rewriting
> d’urls, caches, …)

Mais G-WAN (qui n'a que deux mois) évolue:

SSL est presque fini (sécurisation), et le load-balancing
est prévu 'by-design', les sessions comme les caches
existent déjà, et mon Dieu heureusement il reste le
rewriting d'URL pour justifier l'ajout d'un "framework".

Prions pour que G-WAN n'ait pas l'idée saugrenue
d'ajouter cette fonction-là -ce serait la mort du
 "framework"!

Une petite note d'espoir, dans un monde de brutes...

Pierre (non vérifié) le 19/09/2009

[...] This post was Twitted by eddytilmant [...]

Twitted by eddytilmant (non vérifié) le 02/10/2009

“Google a un projet similaire (traduction de PHP en C),
cela doit donc répondre à un besoin réel.”

C’est en fait Facebook qui vient d’annoncer un “transformateur” de PHP vers C++

http://developers.facebook.com/news.php?blog=1&story=358

Keep the good work Pierre, passion is a fuel for life !

PS: a ready to go package with mysql and a template engine would drive more attention to the project

Not a C developer (non vérifié) le 03/02/2010

@Not a C developer : nous présentons HipHop for PHP ici http://www.greenit.fr/article/energie/hiphop-for-php-facebook-veut-reecr…

admin le 04/02/2010

Poster un nouveau commentaire

Le contenu de ce champ ne sera pas montré publiquement.