Deno vs Java : comparaison des performances du serveur HTTP natif pour le cas hello world
Les articles récents sur la série de comparaisons de performances sont devenus très populaires dans la communauté des médias. Au départ, j'ai fait une comparaison du serveur natif de Node/Deno/Bun avec SpringBoot. J'ai reçu des commentaires selon lesquels il s'agissait d'une comparaison injuste. SpringBoot est un framework et doit être comparé à un framework de l'autre côté. Respectant les commentaires, j'ai fait une comparaison de suivi de SpringBoot avec Node/Deno/Bun fonctionnant sur express/fastify. J'ai encore des commentaires selon lesquels une comparaison des serveurs HTTP natifs des deux côtés serait très utile.
Dans cette série, je vais comparer les serveurs natifs fournis par Node.js, Deno, Bun et Go avec Java. Les autres articles sont :
- Node.js vs Java : Comparaison des serveurs HTTP natifs hello world
- Bun vs Java : Comparaison des serveurs HTTP native hello world
- Go vs Java : Comparaison des serveurs HTTP native hello world
Tous les articles récents sont visibles sur ma page auteur .
La mise en place
Les tests sont exécutés sur MacBook Pro M1 avec 16G de RAM.
Les versions logicielles sont :
- Déno v1.32.3
- Java 20
Déno
Deno.serve((req) => {
try {
if (req.method !== "GET") {
return new Response(null, { status: 405 });
}
const pathName = new URL(req.url).pathname;
if (pathName !== "/") {
return new Response(null, { status: 404 });
}
return new Response("Hello world");
} catch (e) {
return new Response(null, { status: 500 });
}
}, {
port: 3000,
});
import java.io.IOException;
import java.io.OutputStream;
import java.net.InetSocketAddress;
import java.util.concurrent.Executors;
import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpHandler;
import com.sun.net.httpserver.HttpServer;
public class NativeHelloWorldServer {
public static void main(String[] args) throws Exception {
HttpServer server = HttpServer.create(new InetSocketAddress(3000), 0);
server.createContext("/", new MyHandler());
server.setExecutor(Executors.newCachedThreadPool());
server.start();
}
static class MyHandler implements HttpHandler {
@Override
public void handle(HttpExchange t) throws IOException {
String response = "Hello world!";
t.sendResponseHeaders(200, response.length());
OutputStream os = t.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
}
Chaque test est exécuté pour 5 millions (5 millions) de requêtes.
Les tests sont exécutés pour 25, 100 et 300 connexions simultanées.
Le test de charge est effectué à l'aide de l'outil de test HTTP de Bombardier.
Voici les tableaux montrant les résultats pour chaque niveau de simultanéité :
Eh bien, le serveur HTTP natif de Deno s'avère bien plus rapide que le serveur natif de Java. La différence est significative qu'il s'agisse de RPS, de latence ou de ressources système. En outre, Deno utilise moins de ressources système telles que le processeur et la mémoire pour offrir un meilleur RPS.
Je crois que la principale raison est que le serveur ne fait pas grand-chose. Il est principalement lié aux E/S. Lorsque les choses deviennent complexes, je suppose que Java devrait surpasser Node.js, Deno et Bun.
GAGNANT : Deno
Il pourrait y avoir un argument sur l'utilisation du pool de threads mis en cache en Java. L'autre option consiste à allouer un pool de threads de taille fixe au début. Voici un test rapide utilisant 100 connexions simultanées avec un pool de threads de taille fixe de 125 threads. Le seul changement de ligne dans le code Java est :
//server.setExecutor(Executors.newCachedThreadPool());
server.setExecutor(Executors.newFixedThreadPool(125));
Je ne vois aucune amélioration significative des performances avec un pool de threads de taille fixe.
Dans les articles suivants, la comparaison avec Java sera présentée pour Bun, et Go.
Les autres articles disponibles :
![Qu'est-ce qu'une liste liée, de toute façon? [Partie 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)



































