Laut einer Diskussion auf reddit und der element14-Website (Farnell) gibt es jetzt Raspberry Pis mit 512MB RAM (statt 256). Sehr cool. Damit dürfte nun Java ohne Probleme laufen. Bei Element 14 kann man sie schon bestellen!
13.10.2012
Raspberry Pi als Webserver mit PostgreSQL, Ruby und Sinatra
Ein richtiger Webserver braucht eine Datenbank, um dynamischen Content zu erzeugen und ein Framework um den Content auszuliefern. PHP und mySql wird zwar oft verwendet, ich finde das aber eher langweilig.
Deshalb habe ich auf dem RasPi die PostgreSQL-Datenbank installiert, die sehr feine Features hat und Open Source ist.
Als Framework habe ich mir Sinatra ausgesucht. Für die Datenbank-Abstraktion ist Datamapper zuständig. Das ganze wird dann via Rack deployed. Sinatra, Datamapper und Rack sind in Ruby geschrieben, deshalb brauchen wir auch noch einen Ruby-Interpreter. Zunächst verwende ich dazu die Standard-Ruby-Implementierung, für Testzwecke dann auch noch JRuby (Ruby-Interpreter in Java, extra Post). Ruby/Postgres/Sinatra hat den weiteren Vorteil, daß die gleiche Applikation auf Heroku laufen kann, so daß man real-World-Benchmarks fahren kann.
Die Applikation, die ich teste, holt Werte nach Geolocation aus der Datenbank, rechnet einiges daran rum und liefert das per Ajax als JSON an eine Webapp.
Auf dem RasPi ist Soft-float Debian wheezy installiert (JRuby/Java, das ich auch testen will, läuft nur mit dem Soft-Float-ABI) .
Installation, als root auf dem RasPi eingeloggt.
Nun wird die Sinatra-Applikation konfiguriert (Datenbank-User/Verbindung), mit "bundle install" zusammengeschnürt und dann mit "rackup config.ru" gestartet. Die Applikation liefert identisches JSON, wie die Installation auf Heroku. Das ist fein!
Erstes Ziel erreicht: der Raspberry Pi arbeitet als Webserver und liefert dynamischen Inhalt aus einer Datenbank!
Jetzt mal sehen, wie der RasPi sich zum Heroku-Minimal-Setup schlägt.
Als Baseline wird der Apache Bench ("ab") auf Heroku losgelassen. Dort läuft die Applikation in minimaler Ausstattung in der Heroku-free-Variante.
NB: Ich verwende "ab" hier ohne Concurrency mit 500 Zugriffen
Concurrency Level: 1
Time taken for tests: 196.944 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 659000 bytes
HTML transferred: 536000 bytes
Requests per second: 2.54 [#/sec] (mean)
Time per request: 393.888 [ms] (mean)
Time per request: 393.888 [ms] (mean, across all concurrent requests)
Transfer rate: 3.27 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 318
66% 331
75% 337
80% 340
90% 354
95% 375
98% 408
99% 493
100% 10804 (longest request)
Der erste Request nach Heroku dauert sehr lang (etwa 10 Sekunden), Heroku fährt in der Minimalvariante erstmal den Server hoch. Die nachfolgenden Requests dauern zwischen 300ms und 500ms (inclusive Netzwerk-Latenz).
Requests per second: 4.91 [#/sec] (mean)
Time per request: 203.817 [ms] (mean)
Time per request: 203.817 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)
50% 193
66% 194
75% 195
80% 196
90% 197
95% 201
98% 500
99% 507
100% 1707 (longest request)
Wow! Die meisten Requests werden unter 200ms beantwortet. Schneller als Heroku! Allerdings fallen auch keine Netzwerk-Latenzen an, so daß die Werte nicht direkt vergleichbar sind.
Dabei ist die Systemauslastung des RasPi gering:
top - 22:14:41 up 4:27, 3 users, load average: 0.61, 0.43, 0.53
Tasks: 73 total, 1 running, 72 sleeping, 0 stopped, 0 zombie
%Cpu(s): 91.5 us, 3.3 sy, 0.0 ni, 4.6 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
KiB Mem: 236880 total, 148012 used, 88868 free, 11276 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 69740 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8444 pi 20 0 49952 37m 4680 S 80.3 16.3 2:41.88 ruby1.9.1
8970 postgres 20 0 48368 8408 6108 S 12.3 3.5 0:06.70 postgres
9104 postgres 20 0 4660 1372 1048 R 1.3 0.6 0:00.39 top
Es sind noch fast 90MB RAM frei! Postgres langweilt sich. Ich bin begeistert!
Ein Test mit Concurrency 10 schafft genau die gleiche Anzahl von Requests/Sekunde. Nicht schlecht.
Nächster Schritt: Vergleich mit Sinatra unter JRuby,
Deshalb habe ich auf dem RasPi die PostgreSQL-Datenbank installiert, die sehr feine Features hat und Open Source ist.
Als Framework habe ich mir Sinatra ausgesucht. Für die Datenbank-Abstraktion ist Datamapper zuständig. Das ganze wird dann via Rack deployed. Sinatra, Datamapper und Rack sind in Ruby geschrieben, deshalb brauchen wir auch noch einen Ruby-Interpreter. Zunächst verwende ich dazu die Standard-Ruby-Implementierung, für Testzwecke dann auch noch JRuby (Ruby-Interpreter in Java, extra Post). Ruby/Postgres/Sinatra hat den weiteren Vorteil, daß die gleiche Applikation auf Heroku laufen kann, so daß man real-World-Benchmarks fahren kann.
Die Applikation, die ich teste, holt Werte nach Geolocation aus der Datenbank, rechnet einiges daran rum und liefert das per Ajax als JSON an eine Webapp.
Auf dem RasPi ist Soft-float Debian wheezy installiert (JRuby/Java, das ich auch testen will, läuft nur mit dem Soft-Float-ABI) .
Installation, als root auf dem RasPi eingeloggt.
- Postgres-Datenbank, Client und Libraries: apt-get install postgresql postgresql-client libpq5 libpq-dev
- Ruby: apt-get install ruby
- Wir benötigen noch "Bundler", mit dem Ruby alles zum Deployment zusammenschnüren kann: gem install bundler
Nun wird die Sinatra-Applikation konfiguriert (Datenbank-User/Verbindung), mit "bundle install" zusammengeschnürt und dann mit "rackup config.ru" gestartet. Die Applikation liefert identisches JSON, wie die Installation auf Heroku. Das ist fein!
Erstes Ziel erreicht: der Raspberry Pi arbeitet als Webserver und liefert dynamischen Inhalt aus einer Datenbank!
Jetzt mal sehen, wie der RasPi sich zum Heroku-Minimal-Setup schlägt.
Als Baseline wird der Apache Bench ("ab") auf Heroku losgelassen. Dort läuft die Applikation in minimaler Ausstattung in der Heroku-free-Variante.
NB: Ich verwende "ab" hier ohne Concurrency mit 500 Zugriffen
Hier die Ergebnisse von "ab" auf Heroku (500 Requests):
Concurrency Level: 1
Time taken for tests: 196.944 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 659000 bytes
HTML transferred: 536000 bytes
Requests per second: 2.54 [#/sec] (mean)
Time per request: 393.888 [ms] (mean)
Time per request: 393.888 [ms] (mean, across all concurrent requests)
Transfer rate: 3.27 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 318
66% 331
75% 337
80% 340
90% 354
95% 375
98% 408
99% 493
100% 10804 (longest request)
Der erste Request nach Heroku dauert sehr lang (etwa 10 Sekunden), Heroku fährt in der Minimalvariante erstmal den Server hoch. Die nachfolgenden Requests dauern zwischen 300ms und 500ms (inclusive Netzwerk-Latenz).
Nun das gleiche auf dem Rasberry Pi:
Requests per second: 4.91 [#/sec] (mean)
Time per request: 203.817 [ms] (mean)
Time per request: 203.817 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)
50% 193
66% 194
75% 195
80% 196
90% 197
95% 201
98% 500
99% 507
100% 1707 (longest request)
Wow! Die meisten Requests werden unter 200ms beantwortet. Schneller als Heroku! Allerdings fallen auch keine Netzwerk-Latenzen an, so daß die Werte nicht direkt vergleichbar sind.
Dabei ist die Systemauslastung des RasPi gering:
top - 22:14:41 up 4:27, 3 users, load average: 0.61, 0.43, 0.53
Tasks: 73 total, 1 running, 72 sleeping, 0 stopped, 0 zombie
%Cpu(s): 91.5 us, 3.3 sy, 0.0 ni, 4.6 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
KiB Mem: 236880 total, 148012 used, 88868 free, 11276 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 69740 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8444 pi 20 0 49952 37m 4680 S 80.3 16.3 2:41.88 ruby1.9.1
8970 postgres 20 0 48368 8408 6108 S 12.3 3.5 0:06.70 postgres
9104 postgres 20 0 4660 1372 1048 R 1.3 0.6 0:00.39 top
Es sind noch fast 90MB RAM frei! Postgres langweilt sich. Ich bin begeistert!
Ein Test mit Concurrency 10 schafft genau die gleiche Anzahl von Requests/Sekunde. Nicht schlecht.
Fazit
Ein Raspberry Pi kann für eine einfache Sinatra-Anwendung sehr gut mit Heroku in Minimalausstattung mithalten!Nächster Schritt: Vergleich mit Sinatra unter JRuby,
Raspberry Pi als Webserver: maximales RAM einstellen
Um den RasPi als Webserver zu betreiben, braucht man möglichst viel RAM. Die 256 MB, die der RasPi hat, werden beim Booten gesplitted zwischen Hauptspeicher (der ist uns wichtig!) und Speicher für die Videokarte (der ist uns für diesen Anwendungsfall total unwichtig). Dieser sogenannte "Memory Split" kann geändert werden, indem man im /boot-Verzeichnis eine der vorbereiteten start-Files benutzt. Maximales RAM - nämlich 240MB - ergibt bei mir (Debian wheezy) folgendes:
cp /boot/arm240_start.elf /boot/start.elf
dann noch neu starten. Jetzt hat der Kleine nur noch 16MB Video-Ram, aber es ist ja sowieso kein Monitor dran :-)
cp /boot/arm240_start.elf /boot/start.elf
dann noch neu starten. Jetzt hat der Kleine nur noch 16MB Video-Ram, aber es ist ja sowieso kein Monitor dran :-)
03.10.2012
Raspbmc RC5 ist da - mit tollen Features!
Die nächste Iteration von RaspBMC (XBMC-Mediacenter auf Raspberry Pi) ist da! Vor einigen Tagen hatte der Composite-Video-Ausgang (RCA-Stecker) damit noch nicht funktioniert, der Bildschirm blieb schwarz :-(
Heute kam nun eine Ankündigung daß das Problem gefixt ist und tatsächlich: nach dem automatischen Update (wird beim Neustart ausgeführt) funktioniert der Composite-Video-Ausgang wieder!
Wichtigstes neues Feature für mich ist die Wiedergabe von DVD-ISOs. Dank MPEG2-Lizenz und DVD-Menüunterstützung klappt das nun zumindest teilweise - die DVD-Menüs hakeln noch ein bischen. Die Wiedergabe von TS-Dateien (DVB-Transport-Stream im MPEG2-Format) flutscht auch prima.
Raspbmc RC5 ist ein Riesenschritt, das Interface fühlt sich nun wesentlich flüssiger an. Auf der Hardware-Seite hat man nun einige Eingriffsmöglichkeiten mehr zum Übertakten und Feintunen.
Alles in allem unglaublich, was man aus so einer Hardware rausholen kann!
Heute kam nun eine Ankündigung daß das Problem gefixt ist und tatsächlich: nach dem automatischen Update (wird beim Neustart ausgeführt) funktioniert der Composite-Video-Ausgang wieder!
Wichtigstes neues Feature für mich ist die Wiedergabe von DVD-ISOs. Dank MPEG2-Lizenz und DVD-Menüunterstützung klappt das nun zumindest teilweise - die DVD-Menüs hakeln noch ein bischen. Die Wiedergabe von TS-Dateien (DVB-Transport-Stream im MPEG2-Format) flutscht auch prima.
Raspbmc RC5 ist ein Riesenschritt, das Interface fühlt sich nun wesentlich flüssiger an. Auf der Hardware-Seite hat man nun einige Eingriffsmöglichkeiten mehr zum Übertakten und Feintunen.
Alles in allem unglaublich, was man aus so einer Hardware rausholen kann!
Abonnieren
Posts (Atom)