Il offre des performances correctes, il est souple, léger, bref, idéal pour pour héberger des sites à faibles et moyennes frequentations. Il nécessite la version binaire de php pour être exécuté.
Aller plus loin
- nanoweb (14 clics)
nanoweb 1.9
29
oct.
2002
nanoweb est un serveur web ecrit en php, il arrive en version 1.9 avec de nombreux modules et de nombreuses fonctionnalitées.
Il offre des performances correctes, il est souple, léger, bref, idéal pour pour héberger des sites à faibles et moyennes frequentations. Il nécessite la version binaire de php pour être exécuté.
Il offre des performances correctes, il est souple, léger, bref, idéal pour pour héberger des sites à faibles et moyennes frequentations. Il nécessite la version binaire de php pour être exécuté.
# Re: nanoweb 1.9
Posté par Christophe BAEGERT . Évalué à 1.
[^] # Re: nanoweb 1.9
Posté par Stéphane Galland . Évalué à 1.
http://nanoweb.si.kz/?p=perf(...)
Faudrait les comparer avec apache.
[^] # Re: nanoweb 1.9
Posté par Guillaume Smet (site web personnel) . Évalué à 1.
http://www.w3.org/Jigsaw/(...)
Mais ca n'a pas l'air d'être assez lent pour toi :/
Ca doit se tenter en ASP/VbScript.
[^] # Re: nanoweb 1.9
Posté par vrm (site web personnel) . Évalué à 1.
ou
http://jetty.mortbay.org/jetty/(...)
[^] # Re: nanoweb 1.9
Posté par anonyme512 . Évalué à 1.
coté client, c'est certain que même Java 2 (1.2 ou ultérieur) rame, vu que meme swing n'est pas accéléré convenablement niveau affichage. Mais java coté client, c'est quasi complètement mort depuis longtemps, à l'exception d'un ou deux types d'applets relativement largement utilisées (genre applets de chat, etc.), qui sont d'ailleurs souvent pas écrites en swing mais en awt, pour cause de Microsoft :-((
par contre coté serveur, avec la jvm serveur, les native threads (et pas les green threads), et en optimisant correctement le garbage collector, question perfs et stabilité, ça n'a pratiquement rien à envier à des applis natives. Le surcout de la jvm est loin d'etre énorme, et java reste quand même un langage compilé, et non interprété.
de plus il y a aussi gjc pour les plus téméraires...
bon voilà, j'ai marché dans le troll
[^] # Re: nanoweb 1.9
Posté par Moby-Dik . Évalué à 1.
Meuh oui bien sûr.
Un excellent émulateur divisera la vitesse d'exécution par 10. Un bon émulateur, par 100. Un mauvais, par 1000. C'est pas énorme, surtout pour un serveur Web...
[^] # Re: nanoweb 1.9
Posté par Anonyme . Évalué à 1.
Elles sont certes plus puissantes que la machine de test de http://nanoweb.si.kz/?p=perf(...) qui est un Duron 700/1G de ram. Ici, c'est un bi-PIII 1Ghz, 1G de ram, auquel j'ai installé un Tomcat.
La page fait 32Ko. Et ça va 80 fois plus vite que nanoweb:
Document Path: /a.t
Document Length: 32024 bytes
Concurrency Level: 500
Time taken for tests: 0.588 seconds
Complete requests: 1
Failed requests: 0
Broken pipe errors: 0
Total transferred: 145824 bytes
HTML transferred: 142032 bytes
Requests per second: 1.70 [#/sec] (mean)
Time per request: 294000.00 [ms] (mean)
Time per request: 588.00 [ms] (mean, across all concurrent requests)
Transfer rate: 248.00 [Kbytes/sec] received
Et pourtant, y'a la JVM, je comprends pas, ça devrait être plus lent, non?
[^] # Mort de rire :-)
Posté par Moby-Dik . Évalué à 1.
Plus sérieusement, tu devrais faire plkusieurs requêtes à la suite,
sinon le test n'est pas fiable. Augmente la concurrence aussi, surtout que c'est un bi-pro.
Essaie ab -n 500 -c 5 ton_url...
[^] # Re: Mort de rire :-)
Posté par Anonyme . Évalué à 1.
Concurrency Level: 200
Time taken for tests: 9.645 seconds
Complete requests: 5000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 161434044 bytes
HTML transferred: 160248096 bytes
Requests per second: 518.40 [#/sec] (mean)
Time per request: 385.80 [ms] (mean)
Time per request: 1.93 [ms] (mean, across all concurrent requests)
Transfer rate: 16737.59 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 150 758.4 1 9013
Processing: 4 54 295.1 21 3520
Waiting: 2 53 295.2 21 3520
Total: 4 204 907.7 23 9046
Percentage of the requests served within a certain time (ms)
50% 23
66% 28
75% 32
80% 35
90% 45
95% 110
98% 3069
99% 4913
100% 9046 (last request)
Et les voici avec les même paramètres que le test de nanoweb (500/20):
Concurrency Level: 20
Time taken for tests: 0.845 seconds
Complete requests: 500
Failed requests: 0
Broken pipe errors: 0
Total transferred: 16162761 bytes
HTML transferred: 16044024 bytes
Requests per second: 591.72 [#/sec] (mean)
Time per request: 33.80 [ms] (mean)
Time per request: 1.69 [ms] (mean, across all concurrent requests)
Transfer rate: 19127.53 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 2.3 1 16
Processing: 4 19 25.1 16 402
Waiting: 2 19 25.2 15 402
Total: 4 21 24.8 18 402
Percentage of the requests served within a certain time (ms)
50% 18
66% 22
75% 25
80% 26
90% 30
95% 35
98% 40
99% 49
100% 402 (last request)
[^] # Re: Mort de rire :-)
Posté par Moby-Dik . Évalué à 1.
Du reste que PHP était pourri, on le savait depuis longtemps ;-))
(cf. "the great computer language shootout", qui montre que PHP est largement plus lent que Perl sur des tâches équivalentes - http://www.bagley.org/~doug/shootout/(...))
[^] # Re: Mort de rire :-)
Posté par cedric . Évalué à 1.
----
# ab -c100 -n10000 http://plop.linuxfr.org/pub/(...)
(...)
Requests per second: 407.32 [#/sec] (mean)
Time per request: 245.51 [ms] (mean)
Time per request: 2.46 [ms] (mean, across all concurrent requests)
Transfer rate: 8261.69 [Kbytes/sec] received
Note : le serveur est un PII400, la machine d'où provient le test est une machine locale, sur un réseau 100Mbit switché. Le cache est activé, mais la page n'existe pas lors de la première requête. La charge finale est de 12. Pour rappel 400req/sec correspond à 1 milliard de hits par mois environ.
----
C'est bien vous faites a peine mieux qu'un PII400... desole, je sors ;-)
[^] # Re: nanoweb 1.9
Posté par anonyme512 . É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....
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Re: nanoweb 1.9
Posté par wazary . Évalué à 1.
De plus, partir sur l'idée que le php est un language trés lent c'est faux, et nanoweb le prouve bien!
Maintenant je ne suis pas "pro" nanoweb mais je pense juste que le traiter avec un quasi dédain ne fera pas avancer les choses, il vaux mieux tant qu'à faire des remarques qu'elles soit un minimum constructives!
[^] # Re: nanoweb 1.9
Posté par Moby-Dik . Évalué à 1.
(PS : il est où ton bench ?)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: nanoweb 1.9
Posté par Moby-Dik . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: nanoweb 1.9
Posté par Serge2 . Évalué à 1.
[^] # Re: nanoweb 1.9
Posté par Moby-Dik . Évalué à 1.
d'ailleurs si j'étais fan de java, j'utiliserais un wm en java, tiens, ça doit bien exister
[^] # heu
Posté par Moby-Dik . Évalué à 1.
[^] # Re: heu
Posté par Buf (Mastodon) . Évalué à 1.
Mais non, c'est du Goto++...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.