Ca dépend ce que tu programmes et comment tu le programmes.
Si c'est pour programmer ton appli, la différence sera à mon avis négligeable.
Par contre, si tu veux programmer LE serveur web qui ne pense pas mais bosse le plus vite possible, c'est clair que le plus près tu es du système et mieux ça vaut. Mais pour vraiment optimiser, faut meme te mettre dans le kernel-space. Ca vous rappelle quelque chose ?
Par contre, si il s'agit de faire autre chose que d'aller bêtement chercher un fichier sur le disque et de le retourner (ce qui reste un besoin, typiquement pour les images), tout programmer près du système est contre productif et n'apporte pas grande chose dans 90% des cas, voire c'est dangeureux (penser à la sécu..). L'idéal étant d'avoir un système mixte où les pages HTML sont générées par un serveur d'application (écrit en Java, Python, ou autre), et un serveur web plus simple en frontal qui rebalance directement les images. Ca aussi ça existe.
Quand à la jvm, il y a un bon paquet de fonctionnalités qui sont appelées directement dans le système (les threads susnommés par exemple), donc je me demande d'où tu tires tes 10 100 1000.. la jvm n'émule pas une NES, une PlayStation ou que sais-je, c'est beaucoup plus limité et beaucoup plus bas niveau.
Ceci dit, entre du code exécuté par exemple en CGI ou directement dans Apache (via un module), il y a déjà une bonne différence. Par contre entre du CGI et un programme tournant en java, les facteurs ne sont clairement pas ceux que tu évoques (ce doit etre au plus un facteur 2-3), sauf à écrire ton CGI en C, de manière méga optimisée et avec du code assembleur dedans éventuellement, mais ça te prendra pas le meme temps, aura pas la meme stabilité, etc. Quand à programmer un module Apache, ça te prendra également beaucoup de temps et de soucis de stabilité.
En résumé, compare des pommes avec des pommes et des oranges avec des oranges, et tu verras que, pour les besoins coté serveur qu'il remplit, java n'est pas considérablement plus lent que les autres options.
[^] # Re: nanoweb 1.9
Posté par anonyme512 . En réponse à la dépêche nanoweb 1.9. Évalué à 1.
Si c'est pour programmer ton appli, la différence sera à mon avis négligeable.
Par contre, si tu veux programmer LE serveur web qui ne pense pas mais bosse le plus vite possible, c'est clair que le plus près tu es du système et mieux ça vaut. Mais pour vraiment optimiser, faut meme te mettre dans le kernel-space. Ca vous rappelle quelque chose ?
Par contre, si il s'agit de faire autre chose que d'aller bêtement chercher un fichier sur le disque et de le retourner (ce qui reste un besoin, typiquement pour les images), tout programmer près du système est contre productif et n'apporte pas grande chose dans 90% des cas, voire c'est dangeureux (penser à la sécu..). L'idéal étant d'avoir un système mixte où les pages HTML sont générées par un serveur d'application (écrit en Java, Python, ou autre), et un serveur web plus simple en frontal qui rebalance directement les images. Ca aussi ça existe.
Quand à la jvm, il y a un bon paquet de fonctionnalités qui sont appelées directement dans le système (les threads susnommés par exemple), donc je me demande d'où tu tires tes 10 100 1000.. la jvm n'émule pas une NES, une PlayStation ou que sais-je, c'est beaucoup plus limité et beaucoup plus bas niveau.
Ceci dit, entre du code exécuté par exemple en CGI ou directement dans Apache (via un module), il y a déjà une bonne différence. Par contre entre du CGI et un programme tournant en java, les facteurs ne sont clairement pas ceux que tu évoques (ce doit etre au plus un facteur 2-3), sauf à écrire ton CGI en C, de manière méga optimisée et avec du code assembleur dedans éventuellement, mais ça te prendra pas le meme temps, aura pas la meme stabilité, etc. Quand à programmer un module Apache, ça te prendra également beaucoup de temps et de soucis de stabilité.
En résumé, compare des pommes avec des pommes et des oranges avec des oranges, et tu verras que, pour les besoins coté serveur qu'il remplit, java n'est pas considérablement plus lent que les autres options.
Et puis ne pas oublier http://gcc.gnu.org/java/(...) qui permet de pondre du code machine natif....