Java NanoHTTPD - Eine ernstzunehmende Bibliothek, wirklich einsetzbar?

[tuxIt!]

Hallo,

ich bin bei meiner Suche eines einfachen HTTP-Servers für Java, der besonders klein ist und wenige Abhängigkeiten hat auf den NanoHTTPD-Server gestoßen. Ein HTTP-Server in einer Java-Datei, der meinen Anforderungen gerecht wird (bereitstellung einer lokalen Website/max. Intranetseite mit Formular(en)).

Nun meine Frage: was haltet Ihr davon? Kann ich den verwenden? Wie steht es mit der Sicherheit? Wie steht es um die Performance (wie viele Clients verträgt der?)?

Freue mich auf Eure Hinweise,
Gruß,
tuxIt!

P.S.: Jetty und andere Bibliotheken sind mir zu aufgebläht!

 

[Banthor]

Jetty bzw. Tomcat sind deutlich mehr als nur ein HTTP Server, da ist der HTTP-Server darin schon eher der kleinere Teil des Ganzen. Von daher ist es unfair zu sagen, sie seien aufgebläht.

Ich kenne das Framework nicht, aber du kannst es ja einfach mal installieren, ein paar Testseiten erzeugen und dann mal ein Lasttool (z.B. JMeter) drauf loslassen, dann siehst du ja, ob es ein wenig mehr Last taugt.

Da du schreibst dass es eine lokale oder max. Intranet-Website wird, gehe ich mal davon aus, dass der HTTP-Server sich ziemlich langweilen wird.

 

[Firestorm-]

Naja, "ernst nehmen" ist so ne Sache... Ein Tomcat hat im Prinzip den selben Quellcode da stehen, nur eben um viele Module erweitert. Die Abschätzung wieviele Clients damit bedient werden können ist schwer zu treffen. Es kommt darauf an wie die Maschine ist auf dem der Server laufen soll.
Zum Thema Sicherheit kannst du bei Webservern ganze Bücher lesen. Wenn es dir aber nur um den Intranetbetrieb einer Site geht (wo ja sinnvollerweise keine Schnittstelle zum Internet besteht), bist du damit nicht unbedingt falsch beraten denk ich. Aber wie immer und auch hier kommt es schlichtweg darauf an was du konrekt damit vor hast. Wenn du fremdem Code grundsätzlich nicht traust, schreib dir selbst einen kleinen Webserver mit den Funktionen die du brauchst.

 

[tuxIt!]

Danke für die Antworten!

@Anwendungsgebiet
Ich habe eine Software geschrieben, die jetzt noch eine Oberfläche erhalten soll. Dazu habe ich mir ein Webinterface überlegt, da dann auch mehrere Leute im Intranet auf die Oberfläche zugreifen können und Änderungen vornehmen können. Aktionen sind ganz normal (eine Webapp eben): Informationen darstellen (in Liste), Informationen bearbeiten und löschen. Vergleichbar im Umfang mit phpVirtualBox (http://code.google.com/p/phpvirtualbox/) in etwa - es werden nicht riesige Datenmengen durch die Gegend bewegt. Nutzer werden sich vielleicht maximal so 10 damit beschäftigen (eher über den Tag verteilt und maximal gleichzeitig 2).

@Von daher ist es unfair zu sagen, sie seien aufgebläht.
Soll mir recht sein. Aber für meine Anforderungen ist es zu viel.

Alternativ hatte ich noch den "com.sun.net.httpserver.httpserver" gefunden. Der bereits eingebaut ist. Doch leider ist der nicht richtig Dokumentiert, wird von Sun schlecht gepflegt und ist z.B. nicht unter Mac verfügbar.

Ist der denn besser als NanoHTTPD?

Ich will einfach mit diesem Beitrag abklären, ob ich diesen NanoHTTPD nutzen kann in meinem Projekt und ohne Probleme zu bekommen (Security, Performance etc.).

Gruß,
tuxIt!

P.S.: JMeter sieht ja komplex aus. Gibt es nicht bei jedem Apache ein kleines Testprogramm für die Performance?

 

[Banthor]

Wäre ich Du (ich weiß ich bin es nicht), dann würde ich auf jeden Fall Tomcat verwenden. Für Tomcat wirst du auch sehr einfach schnell Hilfe bekommen, falls es mal Probleme gibt.

Immerhin hast du schon eine eigene Javacodebasis, dann willst du es ins Web bringen. Da sind JSP/Servletcontainer wie Tomcat oder Jetty genau richtig.

Von der Sicherheit her ist Tomcat unbedenklich, man muss ihn nur ein wenig konfigurieren. Einige meiner Kunden sind Weltkonzerne und setzen das produktiv ein. Blizzard (gehört jetzt nicht zu meinen Kunden) setzt z.B. ebenfalls Tomcat ein für seine WOW-Seiten.


Wenn du Dich wirklich in einen eigenen puren HTTP-Server einhäkeln willst, dann hast du noch ein paar Aufgaben zu lösen, welche Tomcat schon fertig hat z.B. Request/Response-Encoding, Header, Session-Management, User-Verwaltung.

Wenn du Servlets benutzen möchtest, dann musst du eine wenig die Servlet-API lernen. Das ist aber alles kein Hexenwerk und kann man relativ schnell lernen.

Ergänzung (26. Januar 2011)

EDIT:
JMeter sieht ein wenig komplex aus, ist aber total billig, wenn man erstmal weiß wie es geht. Ich meine es gibt auf den Seiten dort ein "Getting started" was einmal eine normale Performancemessung vorführt.

 

[tuxIt!]

Also, ich möchte unter 200 KB Lib bleiben und werde es auch nicht in das Web portieren. Ich brauche nur die Basisfunktionen, die dieser NanoHTTPD bereit stellt. Alle anderen Funktionen (die darüber hinaus gehen) brauche ich nicht (und habe ich auch keine Zeit für das Projekt an einer komplexen Struktur auszurichten). Und zusätzlich soll es noch relativ stabil funktionieren.

Ich habe mal mit "ab.exe" von Apache den NanoHTTP-Server getestet. Nur etwas hapert es bei mir bei den Interpretationen. Beide male war die CPU-Auslastung auf 100%.

NanoHTTPD:

C:\Programme\xampp\apache\bin>ab.exe -n 100 -c 10 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        144 bytes

Concurrency Level:      10
Time taken for tests:   0.188 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      22600 bytes
HTML transferred:       14400 bytes
Requests per second:    533.33 [#/sec] (mean)
Time per request:       18.750 [ms] (mean)
Time per request:       1.875 [ms] (mean, across all concurrent requests)
Transfer rate:          117.71 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.4      0      16
Processing:     0   16   6.1     16      31
Waiting:        0   12   6.9     16      16
Total:          0   17   5.7     16      31

Percentage of the requests served within a certain time (ms)
  50%     16
  66%     16
  75%     16
  80%     16
  90%     31
  95%     31
  98%     31
  99%     31
 100%     31 (longest request)

Apache:

C:\Programme\xampp\apache\bin>ab.exe -n 1000 -c 10 http://127.0.0.1/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.2.14
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /
Document Length:        234 bytes

Concurrency Level:      10
Time taken for tests:   15.516 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      615000 bytes
HTML transferred:       234000 bytes
Requests per second:    64.45 [#/sec] (mean)
Time per request:       155.156 [ms] (mean)
Time per request:       15.516 [ms] (mean, across all concurrent requests)
Transfer rate:          38.71 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.5      0      31
Processing:    16  154 873.5     63    8859
Waiting:       16  153 873.1     63    8844
Total:         16  155 873.6     63    8859

Percentage of the requests served within a certain time (ms)
  50%     63
  66%     63
  75%     78
  80%     78
  90%     94
  95%    125
  98%    188
  99%   8797
 100%   8859 (longest request)

Gruß,
tuxIt!

 

[ghorst]

Du solltest für einen Vergleichstest die gleiche HTML-Seite ausliefern lassen, sonst sagt es gar nichts. Die Zahl, auf die es primär ankommt, ist Request/sec sowie dessen Standardabweichung. Das solltest du allerdings mit deiner gewünschten Seite ausprobieren und nicht mit der Default-Page des Servers.

Die 100% kommen zu stande, da JMeter schlicht die Lastgrenze austestet.

Ansonsten: Bei der geringen Menge an Usern, die du erwartest, kannst du nehmen, was du willst. Die Leistung ist schlicht irrelevant. Daher lässt sich für dein Problem sagen: Wenn dich ein Server anspricht, alle Funktionalität bietet, die du benötigst und keine nennenswerten Sicherheitslücken bekannt sind, nimm ihn.

 

[tuxIt!]

@ghorst
Danke für Deine Antwort. Ich habe das mit dem Apache-Tool ab.exe getestet. Ich habe eine Demo-HTML-Seite verwendet die merkwürdigerweise unterschiedliche Größen aufweist ... naja, da ist bei mir wohl was schief gelaufen. Aber generell sieht doch der NanoHTTPD besser aus, oder?

@ghorst
Danke für folgenden Rat:

Ansonsten: Bei der geringen Menge an Usern, die du erwartest, kannst du nehmen, was du willst. Die Leistung ist schlicht irrelevant. Daher lässt sich für dein Problem sagen: Wenn dich ein Server anspricht, alle Funktionalität bietet, die du benötigst und keine nennenswerten Sicherheitslücken bekannt sind, nimm ihn.

Okay, ich werde den NanoHTTPD nehmen. Ob Sicherheitslücken bekannt sind weiß ich nicht. Auf der Herstellerseite und im Web habe ich nichts gefunden dazu. Und wenn es nennenswerte gegeben hätte, hätte sich doch vielleicht jemand in diesem Forum gemeldet, oder?

Gruß,
tuxIt!

DANKE