Ich setze seit Jahren auf Apache httpd als Frontend-Server für statische Dateien und Thin dahinter. Hat mir noch nie Probleme verursacht, und die Seiten, die ich betreibe, weisen nicht genug Traffic auf, alsdass ich auf eine performantere Lösung umsteigen sollte.
Früher wurde noch oft Passenger propagiert, aber davon habe ich so lange nichts mehr gehört, dass davon wohl abzuraten ist. Außerdem ist die Konfiguration eines Reverse Proxy jetzt kein Hexenwerk und reduziert die Angreifbarkeit des Frontend-Servers.
slowjack2k hat Recht, was statische Dateien angeht: da sind die „richtigen“ HTTP-Server wie httpd, nginx, usw. schneller und wohl auch sinnvoller. Aus eigener Erfahrung kann ich sagen, dass Thin bei der Auslieferung von wirklich
großen (mehrere GiB) Dateien die Waffen streckt und allen Arbeitsspeicher verbraucht, den es kriegen kann. Außerdem ermöglichen sie umfangreichere Konfigurationsmöglichkeiten. Möglicherweise willst du ja noch mehr auf deiner Seite machen als eine einzige Ruby-Anwendung? Da ist bei einem reinen Application Server (die nicht ohne Grund so heißen) schnell Schluss. Außerdem würde ich mich, bevor ich ein solches Setup fahre, über den Sicherheitsaspekt informieren. Um an Port 80 zu binden, musst du zumindest kurzzeitig root sein, und ich denke (Vorsicht, nicht mit Nachweisen unterlegt), dass Application Server nur selten offen an Port 80 das Internet geklemmt werden und daher nicht dieselbe Sicherheitswartung erfahren wie ein „echter“ HTTP-Server, der speziell dafür gemacht ist.
Welchen der zahlreichen Application- und Frontend-Server du nutzt, hängt von den Anforderungen deines Setups ab, außer natürlich WEBRick, den man niemals in production benutzen sollte. Mit lighttpd hatte ich irgendwelche Probleme, an die ich mich gerade nicht mehr recht erinnern kann, sodass ich für leichtgewichtige Seiten, die nicht viel Konfiguration benötigen, auf
Hiawatha umgestiegen bin, den ich aber noch nicht zusammen mit einem Ruby-Application-Server benutzt habe (sondern nur für reinen statischen HTML-Content). Das muss aber nichts heißen, evtl. ist lighttpd auch das, was du suchst.
Generell wird es bei deiner persönlichen Website faktisch nicht ins Gewicht fallen, welche Kombination du nimmst. Es gibt Spezialserver für spezielle Anwendungsfälle (etwa den speziell für Seiten mit wenig Traffic entwickelten
yahns von Eric Wong), aber für eine Website ohne viel Traffic sollte man die Kombination einsetzen, die einem am meisten zusagt. Sprich, verabschiede dich von Kriterien wie Performanz und suche dir solche, die deiner persönlichen Website, die wohl kaum tausende gleichzeitige Verbindungen aufweisen wird, angemessen sind. Etwa Komplexität der Konfigurationssyntax oder Verwendbarkeit für weitere Anwendungen. Oder Speicherverbrauch. Oder Plattenplatz. Kleine Server haben von beidem nicht viel, sodass hier etwas zum Kriterium wird, das die meisten Appserver-Entwickler nicht auf dem Schirm haben, weil sie für die großen Websites entwickeln, bei denen derartige Probleme naturgemäß nicht auftreten.
Das ist auch der Grund, warum ich als Frontend-Server bisher nicht auf nginx gewechselt bin — mein Blog besteht nur aus statischem HTML, mit der Kommentarfunktion als winzige CGI-Anwendung, weil mehr Flexibilität einfach nicht nötig ist und mir mehr Wartungsaufwand verursachen würde. nginx
kann aber kein CGI (der Versuch, es trotzdem zu machen,
endet gruselig). Damit entfiel nginx für mich und es läuft weiterhin Apache httpd, oder eben Hiawatha.
Vale,
Quintus
_________________
Habe den Mut, dich deines eigenen
Verstandes zu bedienen! — Immanuel Kant
Ich bin freischaffender Softwareentwickler und freue mich über jedes neue Projekt. Kontaktinformation
auf meiner Website.Mein Blog |
GitHub-Profil | Auf Twitter:
@qquintilianus | PGP/GPG-Schlüssel: B1FE 958E D5E8 468E AA20 8F4B F1D8 799F
BCC8 BC4F