IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

ASP.NET Core est le 3e serveur Web le plus rapide, répondant à 7 millions de requêtes HTTP/s,
Selon un test de TechEmpower

Le , par Bill Fassinou

913PARTAGES

14  0 
ASP.NET Core est un framework .NET open source et multiplateforme permettant de créer des applications Web modernes en nuage sous Windows, Mac ou Linux. C'est un framework bâti sur les bases suivantes : multiplateforme, participation de la communauté, performance, modularité, souplesse, etc. Avec ASP.NET Core, il existe désormais deux déclinaisons de la plateforme .NET. Chacune disposant de son propre cycle de développement et les deux bénéficient du support de Microsoft. Bien qu’il s’agisse d’un framework construit sur une nouvelle pile Web, il présente un degré élevé de compatibilité conceptuelle avec ASP.NET MVC.

De ce fait, quelle différence note-t-on entre .NET Core et son homologue .NET Framework ? Contrairement à .NET Framework qui fonctionne uniquement sur Windows ou Windows Server, .NET Core peut être utilisé aussi bien sur Windows que sur Linux et OS X. La conséquence de cette ouverture est le manque de support d’applications qui reposent sur des technologies Microsoft comme WPF, WinForms ou encore ASP.NET WebForms. .NET Core est développé en open source avec la contribution de la communauté. Ce qui n’est pas le cas pour le .NET Framework.

.NET Core implémente de nombreuses API communes avec le Framework .NET. en plus des API qui sont spécifiques à Unix, Linux et OS X. Les API communes sont regroupées dans .NET Standard, qui est implémenté à la fois par .NET Core et .NET Framework. Ce qui signifie que tout code qui cible .NET Standard, peut s’exécuter sur .NET Core et .NET Framework. Cela rend assez simple le partage de code entre les deux plateformes. La dernière version stable du framework, la version 2.2 a été rendue disponible le 4 décembre passé. La version 3.0 quant à elle, est encore en développement. Mais en attendant, une version Preview 2 est disponible avec quelques changements notables tels que la prise en charge des flux asynchrones, la prise en charge des API de port pour Linux, un support pour ARM64 pour Linux, etc.

Pour permettre à ASP.NET de prendre en charge le framework JSON pour .NET dans les projets, il va falloir ajouter Json.NET comme un package indépendant. Toujours sur cette même lancée, l’équipe de Microsoft a décidé de supprimer la prise en charge de la compilation au moment de l’exécution des pages et des vues. Ce changement a été opéré afin de ne plus dépendre du compilateur Roslyn. Après ces mises à jour répétitives qu’a subi le .NET Core, Microsoft a fourni une synthèse sur ses deux outils à savoir le .NET Core et le .NET Framework, qui montre que .NET Core est plus performant que le .NET Framework.


À la vue de cela, un internaute explique que Microsoft a beaucoup travaillé pour améliorer les performances du .NET Core par rapport à .NET Framework. Pour lui, certains sujets restent encore à la traîne, mais d’autres par contre, ont été revus en profondeur. LINQ est devenu omniprésent ces dernières années, dit-il. La sérialisation, la compression, le networking, etc. dans les Web API sont bien plus rapides dans .NET Core que dans .NET Framework.
Ainsi, TechEmpower (un framework d’applications Web qui compare les projets offrant des services de conception, de stratégie, de gestion, de systèmes et de graphisme) a réalisé récemment une comparaison entre la version stable 2.2 de .NET Core avec plusieurs autres frameworks d’applications Web, d'infrastructures full-stack et micro-frameworks. Les résultats placent ASP.NET Core comme 3e serveur le plus rapide. Il est capable de répondre à 7 millions de requêtes HTTP en seulement une seconde.

Ces résultats concernent le serveur Web et le testeur de charge s’exécutant dans des conteneurs Docker, sur deux machines Linux physiques différentes connectées à un réseau de 10GbE, a écrit Ben Adams de Age of Ascent, qui rapporte les différents résultats des tests. « C'est aussi une quantité extraordinaire de bande passante ; assez pour saturer en permanence un lien de 10 Go/s », a-t-il estimé. Selon lui, ASP.NET Core serait très rapide sur toutes les plateformes et l’est plus encore lorsqu’il s’agit de Linux. Dans la comparaison avec d’autres serveurs bien connus, les résultats montrent qu’il est 1,78 fois plus rapide que nginx ; 2,93 fois plus rapide que le servlet de Java ( 7,76 fois plus rapide que le servlet sur Tomcat) ; 7,36 fois plus rapide que le package “net/HTTP” de Golang ; 8,06 fois plus rapide que node.js fonctionnant en cluster de 28 processus (car node.js est à thread unique).


Dans ce dernier cas, certains internautes indiquent que Node.js est totalement dépassé par les performances de ASP.NET Core et cela, quels que soient l’OS, le type de machine et le nombre de cœurs. Ils soulignent notamment les performances remarquables du framework sur Linux. La petite surprise, disent-ils, c’est les bons chiffres sur Ubuntu et ses pairs. On sent que la firme de Redmond a vraiment travaillé sur l’implémentation du .NET Core sur Linux, disent-ils. Néanmoins, ils soulignent quelques imperfections, rien n’étant jamais parfaite à 100 %. « Après, même si cela n’apparaît pas dans les chiffres, il y a tout de même quelques bémols. En effet, sans la désactivation des logs, les performances d'une ’application Web ASP.NET Core sont divisées par environ 5. Ce qui, lors des tests sur Windows, causait des erreurs sur 1 à 2 % des requêtes. Or, une application sans log n’est pas très réaliste en production », ont-ils déclaré.

Ils conseillent donc de préférer les fonctions qui facilitent le développement comme le nouveau concept de Middleware et de Pipeline. D’autres tests réalisés pour examiner les performances de ces outils sur une base de données montrent que ASP.NET Core peut fonctionner avec de nombreuses bases de données (Postgres, MySQL, etc.) avec des performances très remarquables. Il existe d’autres résultats des tests que vous pouvez visualiser sur le site Age of Ascent. D’après Adams, .NET et ASP.NET ont toujours été très productifs et l’avenir avec ASP.NET Core et .NET Core sera aussi productif que rapide.

Sources : Age of Ascent, TechEmpower

Et vous ?

Que pensez-vous des résultats de ce test ?
ASP.NET Core est-il vraiment meilleur que les autres serveurs Web courants, selon vous ? Pourquoi ?
Quel est votre serveur Web préféré et pourquoi ?
Quelles expériences avez-vous faites d'ASP.NET Core ?

Voir aussi

.NET Core ou .NET Framework ? Quelle implémentation adopter pour son projet ?

ASP.NET Core 2.2 est disponible en version stable avec un nouveau module d'hébergement dans IIS et une nouvelle API pour suivre l'état des apps

ASP.Net Core 3 Preview 2 est disponible avec la prise en charge de Razor Components et l'intégration du streaming client-serveur avec SignalR

Apprendre à créer une application CRUD avec ASP.NET Core Razor Pages sous Visual Studio Code et Entity Framework Core, un tutoriel d'Hinault Romaric

Apprendre à déployer une application ASP.NET Core avec un conteneur Docker, un billet d'Hinault Romaric

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Dasoft
Membre actif https://www.developpez.com
Le 04/12/2019 à 10:33
@matthius : ta totale ignorance démontre que ton savoir-faire n'est qu'à ses débuts
3  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 30/09/2019 à 12:27
Citation Envoyé par dfiad77pro Voir le message
je doute que Microsoft investisse dans la création d'un Framework multi-plateforme…
En fait si, il y a Xamarin pour du multi-plateforme utile : le mobile.
Les IHM sur du linux desktop ca touche tellement peu de cas que c'est s'attirer beaucoup d’emmerde pour pas grand chose.
2  0 
Avatar de freesket
Membre du Club https://www.developpez.com
Le 01/10/2019 à 8:03
Xamarin.Forms est multiplateforme : Windows UWP, IOS, Android mais aussi (en preview pour le moment) Linux (GTK), MacOs et Windows desktop (WPF) :
https://docs.microsoft.com/en-us/xam...latform/other/
2  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 17/10/2019 à 16:57
Citation Envoyé par denisys Voir le message
Etant déçus des résultat de .Net Core 3.0 , je préfère continuer a utiliser mono , pour le portage des applications WinForm , sur linux et mac .
https://www.mono-project.com/
Ce serai bien que tu développe un peu, ça pourrai toujours être intéressant de savoir pourquoi...
2  0 
Avatar de rt15
Membre éclairé https://www.developpez.com
Le 11/02/2019 à 17:40
Pardon mais en première lecture j'ai trouvé ces résultats suffisamment surprenant pour me demander si c'était pas pondu par une boîte, comment dire, légèrement influencée par M$.
Genre une boîte qui vend des produits basés sur ASP.NET et qui est toute contente d'avoir comme par hasard choisi la meilleur technologie.

Pour remettre dans le contexte, il y a quelques années, je me suis un peu intéressé à nodejs.
Avant cette étude, j'imaginais qu'un serveur en nodejs devais être au mieux 20 ou 30% plus lent qu'un serveur en C, C++ ou en Java.
Généralement le javascript peut difficilement espérer faire mieux, même exécuté par le V8 de Google qui est utilisé par nodejs.

Je me disais que les utilisateurs de nodejs acceptaient cette perte de performance.
Mais en fait pas du tout.
L'architecture d'un serveur nodejs est bien différente de la plupart des serveurs de l'époque.
Alors que beaucoup utilisaient (et utilisent encore) un thread par requête HTTP et parallélisaient les traitements sur différents coeurs, nodejs utilise un seul thread (du point de vue du développeur JS) et se base sur les entrées sorties asynchrones.

Le coeur de nodejs, c'est libuv, une bibliothèque écrite en C par le créateur de nodejs.
Cette librairie permet avant tout de faire en asynchrone les I/O sur les sockets et les disques.

En gros le thread principal ne fait que soumettre des demandes de "tâches" au système d'exploitation, du genre écrit moi ça sur telle socket.
Mais le thread n'attends pas la fin de la lecture ou de l'écriture : la demande de l'exécution d'une tâche n'est pas bloquante.
Au lieu de cela, le thread principal se met en attente sur un ensemble d’évènements tels que "fin de l'écriture" ou "il y a quelque chose à lire sur tel socket".
Le système réalise les tâches en arrière plan et notifie quand elles sont terminées.
Dès qu'un événement se déclenche, le thread principal va le traiter, généralement en soumettant de nouvelles tâches d'entrée/sortie, puis se remettre en attente d'un nouvel évènement.
De cette manière le thread principal a "très peu" de travail et peut gérer des quantités astronomiques de connections et de lectures/écritures sur disque.
Le fait d'avoir peu de threads est très avantageux par rapport à un serveur classique car quand le processeur change de thread, il faut qu'il remplace son contexte d'exécution et ça prend un certain temps.
Ce contexte et la pile associée au thread prend aussi de la place en mémoire.
Par contre le désavantage d'avoir un seul thread principal est que si on a besoin de faire une tâche gourmande en CPU et qu'on l'a fait en JS, ça va bloquer le thread principal et le serveur ne fera rien d'autre : il ne sera pas à l'écoute des évènements pendant ce temps là.

Le résultat c'est que pour certaines applications, un serveur nodejs ne vas pas être 20 ou 30% plus lent qu'une appli JEE. Le serveur nodejs peut battre le JEE à plate couture.
Mais ce n'est pas JS qui est plus rapide que le Java. C'est la librairie C libuv qui bat l'archi JEE.

Donc sachant la qualité de l'approche et de l'implémentation de nodejs dans ce domaine, j'ai été surpris que aspcore puisse écraser nodejs sur un "Best plaintext responses per second".

Qu'est ce qui peut expliquer une telle différence ?
En y regardant de plus près, a priori, le serveur web utilisé par ASP.NET Core dans ce benchmark s'appelle Kestrel (c'est celui par défaut).
https://github.com/TechEmpower/Frame...rks/Program.vb
(à noter qu'ils ont implémentés le benchmark en VB, pas en C#!)

Et devinez sur quoi est basé Kestrel à la base ? Sur libuv...

Depuis l'utilisation de libuv a été supprimé mais en fin de compte la nouvelle implémentation se base certainement sur epoll sous Linux et les Overlapped I/O sous Windows.
Kestrel s'appuie donc sur les mêmes fonctions systèmes que libuv.

En tout cas chapeau aux développeurs C/C++ de M$ pour leur résultat sur ce bench.
1  0 
Avatar de FatAgnus
Membre chevronné https://www.developpez.com
Le 26/09/2019 à 21:16
Citation Envoyé par kilroyFR Voir le message
Ca n'aura de réel intérêt que le jour ou ca ne fonctionnera pas QUE sous Windows (WPF/WinForms j'entends). Le reste c'est du détail.
Microsoft ne veut pas pas d'une implémentation multiplate-formes de Windows Forms ou WPF, c'est eux même qui l'écrivent sur la page Contributing Guide : « Nous n'avons pas non plus l'intention d'accepter des contributions qui fournissent des implémentations multiplate-formes pour Windows Forms ou WPF. ».
2  1 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 27/09/2019 à 21:01
Citation Envoyé par kilroyFR Voir le message
Ca n'aura de reel interet que le jour ou ca ne fonctionnera pas QUE sous windows (WPF/Winforms j'entends). Le reste c'est du detail.
Déjà winform ne fonctionnera jamais en dehors de Windows, et Wpf non plus. L'un est une flat api par dessus win32 le second utilise massivement directX.

Il a des mots clefs dans ces technologies comme Windows ou Win32... Ce qui laisse peu de doute concernant la portabilité.

Votre commentaire montre que vous ne semblez pas comprendre le fonctionnement des apis que utilisez ce qui est extrêmement inquiétant si vous êtes un professionnel.
2  1 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 01/10/2019 à 21:46
Citation Envoyé par micka132 Voir le message
Les IHM sur du linux desktop ca touche tellement peu de cas que c'est s'attirer beaucoup d’emmerde pour pas grand chose.
Oui et non.

En portant son SGBD SQL Server sous Linux, ainsi que son framework de développement .NET sous Linux, Microsoft s'ouvre clairement la voie vers ce système.
A ça, on combine le sous-système Linux pour Windows, et on en arrive à se demander quand des outils tels que Microsoft Office, qui sont déjà portés sous Mac OS... qui n'est qu'un Linux après-tout, seront enfin portés sous Linux.

Si je ne m'abuse, Visual Studio Code tourne sous Linux... pour quelle sombre raison SQL Server Management Studio, actuellement développé en .NET, ne serait pas porté sous Linux lui aussi ? C'est juste logique d'offrir un environnement complet de développement et d'administration SQL sous Linux.

Bref, si Microsoft ne se lance pas ouvertement dans le développement de logiciels grand public sous Linux, le simple fait d'avoir mis de côté le projet Mono au profit de .NET Core montre que Microsoft se recentre clairement sur Linux, et que l'objectif est bel et bien de ne pas seulement faire tourner ses langages sous Linux, mais bien de s'approprier Linux et devenir une plateforme de choix, y compris pour des projets 100% Linux. A partir de là, que ce soit Windows.Forms, WPF, UWP ou n'importe quoi de nouveau, Microsoft finira bien par se lancer dans les IHM multiplateforme.

Le simple fait que Microsoft développe en masse pour Android (qui, rappelons le, est basé sur Linux) montre bien cette volonté de ne plus devenir un choix des "windowsiens qui essaient de faire marcher leurs trucs ailleurs que sous Windows", mais bien une alternative réelle à Java... qui dispose d'IHM sur toutes les plateformes depuis toujours.
Actuellement, l'absence d'IHM portable est la seule réelle tare que traîne .NET face à Java.
1  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/10/2019 à 4:29
pour les databases Microsoft à un logiciel electron basé sur vscode (mais vraiment différent), ça ne remplace pas le management studio mais c'est un bon début.
https://github.com/microsoft/azuredatastudio
1  0 
Avatar de xarkam
Membre éprouvé https://www.developpez.com
Le 03/10/2019 à 20:32
Citation Envoyé par rt15 Voir le message
Bof. Désolé, je partage pas du tout cette analyse.

Accessoirement il me semble que le Java est complètement has been sur mobile (bouffé par javascript, Dart, Kotlin...) et de toute façon pour les interfaces graphiques, les librairies historiques portables Swing et JavaFX sont pas utilisées sur mobile.
Dart transpilé en java, Kotlin qui n'est qu'une surcouche pour apporter de la modernité à java.
Malgré que java passe pour un hasbeen sur mobile, sauf cordova, (il me semble que le reste transpile en java ou mettent un interpréteur), java sous android reste le best en terme de perf.

Citation Envoyé par rt15 Voir le message

Les applications desktop ça devient de plus en plus has been aussi, tout se fait de plus en plus dans le navigateur.
Par exemple pour Office, plutôt qu'un portage Linux, M$ a fait un portage (partiel) sur le web en proposant "Office Online"/"Office Web Apps"/"Office for the web"/"Office in a browser".
Mais bien sur. Pour des besoins ultra simple c'est ok, sinon office web ca vaut pas la peine. C'est plus un viewer web qu'autre chose.
Un exemple récent (avant hier), j'ai fait une présentation powerpoint via teams et j'ai eu besoin de faire une modification et ensuite grouper les éléments. Ca n'est pas dispo dans la version web.
Je pourrais dresser une liste assez longue de ce qui n'est pas dans les version web.
Quant à electron, prévoyons des machines dans le future avec 128gb ram vu comment sa prend des ressources.

Citation Envoyé par rt15 Voir le message

Le combat Java vs C# (pas seulement niveau appli desktop où ils n'ont jamais vraiment percé) va pas perdurer bien longtemps s'ils se font complètement démonter par pléthore de nouvelles technos (node.js...) et autres langages (Go...) qui sont vachement hypés.
Alors, pour ce qui est de la france, en dehors de php et java, nulle espoir. D'ailleurs en france on forme des dev php à tour de bras.
Dans le reste du monde, les dev c# sont hyper courtisés justement depuis le renouvellement de c#
(ma femme et moi sommes des dev c# et nous pourrions changer de boite tout les mois. Ca en devient lassant ces relances pour bosser chez l'un et l'autre)

Pour moi la guerre java vs c# n'existe plus depuis belle lurette. C# apporte plein de modernité dans le langage que n'a pas java.
Pourtant, java rattrape doucement son retard, mais les applications métiers restent encore sur java 8.

Blazor quant à lui apporte une manière de coder à la react. J'ai vu dernièrement une vidéo montrant du débug de code c# directement dans les devtools de edge chromium. Bluffant.
1  0