Czy RoR działa z lighttpd?

Nie znam Ruby, ale znalazłem redmine’a napisanego w nim, który spodobał mi się. To taka aplikacja do pilotowania projektów. Zainstalowałem ją i działa, ale lokalnie pod adresem: http://127.0.0.1:3000 . Wszystko pięknie i ładnie ale chciałbym ja udostępnić poblicznie i to na interfejsie fastcgi.

Od lat moim web-serwerkiem jest lighttpd. Łatwy w konfiguracji (do dzisiaj…) i fastcgi śmigało (c++, perl, php). Ale ta bestia redmine nie chce łazić pod lighttpd (błąd 500 - wewnętrzny błąd serwera). I tu moje pytanie: Czy ktoś z Was ma pozytywne doświadczenie w uruchomieniu aplikacji RoR (najlepiej redmine’a) pod lighttpd? Gdyby tak, to proszę o pomoc.

Mój serwer to Debian:

Linux borsuk 2.6.32-2-amd64 #1 SMP Fri Feb 12 00:01:47 UTC 2010 x86_64 GNU/Linux

ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

lighttpd/1.4.26 (ssl) - a light and fast webserver/ Build-Date: Jun 3 2010 19:56:50

Pozdrawiam!

Obawiam się, że możesz mieć problemy ze znalezieniem kogoś, kto jeszcze używa fastcgi przy hostingu aplikacji railsowych. Fastcgi jest już od dawna prawie nieużywane ze względu na to, że jest w porównaniu do innych rozwiązać obecnie stosowanych dość niestabilne.

Obecnie najczęściej wykorzystywane są 2 sposoby:

  1. passenger - plugin do nginxa i apacha, który umożliwia banalnie proste podpięcie railsów pod dowolnego vhosta
  2. serwer aplikacyjny (np: mongrel, unicorn lub thin) + dowolny serwer http jako proxy

W Twoim przypadku (zakładam, że nie chcesz się przesiadać na nginxa lub apacha) polecam rozwiązanie 2. Stawiasz aplikację używając np. thina i w lighttpd ustawiasz proxy na np. 127.0.0.1:4000 (zakładając, że thin stoi na porcie 4000). Dobrze jest też ustawić monita, żeby monitorował czy thin stoi i w razie czego stawiał go do pionu.

[quote=drogus]Obawiam się, że możesz mieć problemy ze znalezieniem kogoś, kto jeszcze używa fastcgi przy hostingu aplikacji railsowych. Fastcgi jest już od dawna prawie nieużywane ze względu na to, że jest w porównaniu do innych rozwiązać obecnie stosowanych dość niestabilne.

Obecnie najczęściej wykorzystywane są 2 sposoby:

  1. passenger - plugin do nginxa i apacha, który umożliwia banalnie proste podpięcie railsów pod dowolnego vhosta
  2. serwer aplikacyjny (np: mongrel, unicorn lub thin) + dowolny serwer http jako proxy

W Twoim przypadku (zakładam, że nie chcesz się przesiadać na nginxa lub apacha) polecam rozwiązanie 2. Stawiasz aplikację używając np. thina i w lighttpd ustawiasz proxy na np. 127.0.0.1:4000 (zakładając, że thin stoi na porcie 4000). Dobrze jest też ustawić monita, żeby monitorował czy thin stoi i w razie czego stawiał go do pionu.[/quote]
Dzięki za odpowiedź!

Do lighttpd jestem przywiązany ale nie uwiązany :slight_smile: - na nginxa mógłbym się przesiąść. Na inny zresztą też. Do apache’a nie mam kompletnie zaufania z powodu jego ciężkości (doświadczenie sprzed paru lat). Czy gdzieś są dostępne materiały jak uruchomić RoR na nginxa?

Rozwiązanie serwaera aplikacyjnego to dla mnie zupełna nowość. Chętnie się czegoś nauczę! W takim jednak przypadku chciałbym solidnego rozwiązania na parę lat. Każde rozwiązanie jednak musi byc proste i pod debiana 64. Nie jestem czystej wody webserwerowcem a i aplikacje nie będą istotnie obciążane, tak, że nawet w dzisiejszych czasach (choć na granicy) i zwykłe CGI by wystarczyło (no może jednak jest za wolne).

To co MUSZĘ uruchamiać na serwerze to standard html + fastcgi perlowe. Co doradzasz?

Pozdrawiam!

w google są wszystkie potrzebne informacje

Ja bym zostawił to co masz teraz, żeby nie bawić się niepotrzbnie w konfigurację. Do sprawdzenia najłatwiej postaw aplikację używając ./script/server i spróbuj ustawić na nią proxy: http://redmine.lighttpd.net/wiki/1/Docs:ModProxyCore

Z tego co widzę, to można również w “backends” w lighttpd ustawić sockety, więc jak już uda Ci się odpalić zwykłe proxy, to możesz się pobawić w podpięcie backandu przez sockety (tutaj jest przykład jak podpiąć thina do nginxa poprzez sockety: http://code.macournoyer.com/thin/usage/, ale dokładnie tak samo musisz uruchomić thina, żeby działał z lighttpd, jedyne co ja bym zmienił to ilość serwerów, w przykladzie są odpalane 3, podejrzewam, że wystarczy Ci jeden)

Uzywam lighttpd w debianie i ma to tak zrobione:
tworzysz plik /etc/lighttpd/conf-available/10-rail.conf
a w nim
#################
$HTTP[“host”] =~ “(^|.)(domena.pl)$” {
var.railsdir = “/var/rails/rail_app”

    server.error-handler-404 = "/dispatch.fcgi"
    server.document-root = var.railsdir + "/public/"

url.rewrite = ( “^/$” => “index.html”, “^([^.]+)$” => “$1.html” )
fastcgi.server = ( “.fcgi” => ( “localhost” => (
“min-procs” => 3,
“max-procs” => 4,
“socket” => var.railsdir + “/tmp/sockets/lighttpd/fcgi.socket”,
“bin-path” => var.railsdir + “/public/dispatch.fcgi”,
“bin-environment” => ( “RAILS_ENV” => “production” )
) ) )
##################

następnie komenda:
lighty-enable-mod rail
/etc/init.d/lighttpd reload

W katalgou aplikacji musi znjadowac sie dispatch.fcgi
jesli go niemasz to jego zawartosc ponizej:
################
#!/usr/bin/ruby

require File.dirname(FILE) + “/…/config/environment”
require ‘fcgi_handler’

RailsFCGIHandler.process!
#####################

no i to powinno wystarczyć narazie niewidze potrzeby rezygnowania z lighttpd oraz tej metody

Dziękuję wszystkim za uwagi! Lighttpd ma tę wielką zaletę, że działanie serwera związane jest z plikami (np. rozszerzenia) a nie z katalogami typu cgi-bin, dzięki czemu można to wszystko mieszać. Ja np. uruchamiam aplikacje perla metodą fastcgi i tak podniesiona aplikacja może już np metodą eval dynamicznie uruchamiać różne pożądane pod-skrypty perla.

nginx w ogóle ignoruje cgi, co czasem nie jest wygodne. Bardzo ciekawie wyglądał cherokee, ale napisali że fastcgi jest jakies brrzydkie dla railsów (z winy railsów jak napisali)

drusslow! Dzięki za wlanie nadziei w działanie w ramach lighttpd!

Dobranoc!

To trochę dłuższa, starsza i bardziej skomplikowana historia jest :wink:

http://www.nginx.eu/nginx-fcgi.html ?

Niedawno powstał też “tłumacz” protokół CGI na FastCGI do nginxa:
http://github.com/gnosek/fcgiwrap

Dżizas, ludzie, opanujcie się! FastCGI to koszmar przez który nie chcecie przechodzić.

Nginx, Apache - użyj Passengera.

Każdy inny serwer HTTP - odpal Mongrela albo coś i zrób proxy na ten port. W necie jest milion instrukcji, na pewno też na tym forum.

SOLVED!

Bardzo dziękuję. Rzeczywiście rozwiązanie poprzez proxy jest o niebo prostsze. Sprawa wydajności w tym przypadku nie jest dla mnie jasna, ale w tym momencie nie jest też ważna. Do lighttpd dodałem moduł mod_proxy i wstawiłem wiersze:

$HTTP[“host”] == “redmine.moja-domena.pl” {
proxy.balance = “hash”
proxy.server = ( “” => ((
“host” => “127.0.0.1”, “port” => 3000
)))
}
i Redmine działa.

Dzięki Wam wszystkim raz jeszcze!

wb

Zapewniam Cię, że na mongrelu (lub nawet jeszcze lepiej, thinie albo unicornie, które są szybsze) wyciągniesz więcej niż na fcgi :slight_smile:

być może, być może. Chodziło mi nie o porównanie z innymi serwerami ale porównanie udostępniania przez proxy w porównaniu do fcgi (mitycznego, bo nie uruchomiłem go :slight_smile: .

Zapewniam Cię, że na mongrelu (lub nawet jeszcze lepiej, thinie albo unicornie, które są szybsze) wyciągniesz więcej niż na fcgi :)[/quote]
być może, być może. Chodziło mi nie o porównanie z innymi serwerami ale porównanie udostępniania przez proxy w porównaniu do fcgi (mitycznego, bo nie uruchomiłem go :slight_smile: .[/quote]
No więc powierzchownie porównałem szybkościowo dwie aplikacje (zainstalowane na tym samym serwerze:

  1. perl/fastcgi (z 1 selectem do postgresa) i z lighttpd jako serwerem.
    2 redmine (strona startowa redmine z listą dwóch projektów. Nie wiem co tam robi z bazą ale to też postgres na tym samym lokalnym serwerze)

Wyniki mówią same za siebie, no ale w tego typu aplikacji jak Redmine szybkość nie jest ważna. Oczywiście wielką niewiadomą jest współpraca z bazą danych, chociaż szybsza dwa razy aplikacja danych ściaga z bazy także i to w sumie 5 razy więcej danych, czyli naiwnie licząc jest 10 razy szybsza.

Zwróćcie uwagę, że ja bezpośrednio łączyłem się z Redminem: 127.0.0.1:3000 a nie za pośrednictwem proxy.

=============================

ab -n 100 127.0.0.1:3000/

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: WEBrick/1.3.1
Server Hostname: 127.0.0.1
Server Port: 3000

Document Path: /
Document Length: 3239 bytes

Concurrency Level: 1
Time taken for tests: 5.199 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 369406 bytes
HTML transferred: 323900 bytes
Requests per second: 19.23 [#/sec] (mean)
Time per request: 51.990 [ms] (mean)
Time per request: 51.990 [ms] (mean, across all concurrent requests)
Transfer rate: 69.39 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 33 52 43.4 36 233
Waiting: 33 52 43.4 35 233
Total: 33 52 43.4 36 234

Percentage of the requests served within a certain time (ms)
50% 36
66% 37
75% 40
80% 41
90% 86
95% 178
98% 184
99% 234
100% 234 (longest request)

=============================

ab -n 100 seal.sao.pl/seal?item=1002

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 seal.sao.pl (be patient)…done

Server Software: lighttpd/1.4.26
Server Hostname: seal.sao.pl
Server Port: 80

Document Path: /seal?item=1002
Document Length: 17777 bytes

Concurrency Level: 1
Time taken for tests: 3.730 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 1787838 bytes
HTML transferred: 1777700 bytes
Requests per second: 26.81 [#/sec] (mean)
Time per request: 37.296 [ms] (mean)
Time per request: 37.296 [ms] (mean, across all concurrent requests)
Transfer rate: 468.12 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 1 0.1 1 2
Processing: 18 36 4.8 36 49
Waiting: 15 32 4.8 33 45
Total: 20 37 4.9 38 51

Percentage of the requests served within a certain time (ms)
50% 38
66% 39
75% 39
80% 39
90% 40
95% 41
98% 49
99% 51
100% 51 (longest request)

@Waldemar: Porównujesz “jabłka z pomarańczami”. Ta aplikacja w Perlu na Lighttpd to domyślam się nie Redmine ? :wink:
Nawet jeśli strona startowa Redmine robi 1 select’a do bazy (a robi więcej) to select select’owi nie równy, poza tym pozostaje kwestia aplikacji. To tak jakbyś robił benchmark, która benzyna jest lepsza 95 czy 98, wlał 98 do Fiata 126p i 95 do Opla Corsy i stwierdził, że Opel do 100km/h rozpędził się szybciej więc 95 jest lepsza.

Jeśli chcesz porównać Fcgi+Lighttpd z Mongrel’em/Thinem to postaw Redmine na Lighttpd jako fcgi i wtedy rób benchmarki. IMHO benchmarki Fcgi to strata czasu, temat był wałkowany 4 lata temu kiedy nic lepszego niż Fcgi nie istniało i od momentu kiedy pojawił się Mongrel i Thin wszyscy jednogłośnie uznali, że “Fast” nie oznacza “szybki” i nikt już tego nie używa (domyślam się, że Fcgi jest wciąż popularne wśród Perl’owców ? )

[quote=hosiawak]@Waldemar: Porównujesz “jabłka z pomarańczami”. Ta aplikacja w Perlu na Lighttpd to domyślam się nie Redmine ? :wink:
Nawet jeśli strona startowa Redmine robi 1 select’a do bazy (a robi więcej) to select select’owi nie równy, poza tym pozostaje kwestia aplikacji. To tak jakbyś robił benchmark, która benzyna jest lepsza 95 czy 98, wlał 98 do Fiata 126p i 95 do Opla Corsy i stwierdził, że Opel do 100km/h rozpędził się szybciej więc 95 jest lepsza.

Jeśli chcesz porównać Fcgi+Lighttpd z Mongrel’em/Thinem to postaw Redmine na Lighttpd jako fcgi i wtedy rób benchmarki. IMHO benchmarki Fcgi to strata czasu, temat był wałkowany 4 lata temu kiedy nic lepszego niż Fcgi nie istniało i od momentu kiedy pojawił się Mongrel i Thin wszyscy jednogłośnie uznali, że “Fast” nie oznacza “szybki” i nikt już tego nie używa (domyślam się, że Fcgi jest wciąż popularne wśród Perl’owców ? )[/quote]
Oczywiście, że porównuję jabłka z pomarańczami. Jak chce mi się jeść to patrzę nie tylko co ale i jak i gdzie chcę jeść, chyba, że umieram z głodu. Dlatego napisałem wyraźnie “powierzchownie”. Chciałem porównać aplikację “z marszu” tak jak ją dostarczyli z czymś co znam i rozumiem. Zatem zamknijmy temat benchmarku. Wierzę, że railowcy doprowadzili to do perfekcji.

Chodzi mi o coś innego.

Wyobraźmy sobie, że mam do zrobienia całkiem nowy i całkiem spory projekt dla biznesu. Oczywiście robię je od tylu lat, że już nie chcę liczyć :). Oczywiście słyszałem już wielokrotnie o Railsach a tu nagle - poszukują prostej postgresowej aplikacji do zarządzania uwagami o projekcie natrafiam na sympatyczną i niedużą aplikację Redmine, którą łatwo zainstalowałem i chodzi pod moją ulubiona bazą. Z “natury” jestem perlowcem i daje mi to do myslenia: dlaczego nie ma (ja nie znalazłem) w Perlu takiej aplikacji - teoretycznie jest ich mnóstwo. OK, może czas się przesiąść? Więc sprawdzam i wącham wkoło: może czas napisać nową aplikacje w czymś lepszym? Znam zalety i wady Perla i akurat składnia i taka obiektowość jaką prezentuje Perl nie jest przeszkodą - wręcz przeciwnie - osobiście bardzo mi filozofia Perla pasuje. A zwłaszcza jego składnia. Wiem! słyszałem i o kocie Schrodingera (tego z mechaniki kwantowej) i o kocie twórcy Perla co to łaził po klawiaturze, ale właśnie składnia Perla była tym czymś co spowodowało moje prawdziwe zainteresowanie tym językiem.
Co nie znaczy, że z Perlem brałem z nim ślub.

Po prostu rozglądam się i pytam bardziej doświadczonych. Język programowania służy mi do pisania programów nie do zachwytów nad nim. Gdyby płacili mi od godziny to pisałbym w assemblerze i to w dodatku stukałbym tylko jednym palcem , ale nie chcą :). Dlatego szukam języka pomocnego. Jestem odporny na hasła od czasu, gdy zobaczyłem język programowania, który potrafił byc do 10 razy szybszy (w programowaniu dużych aplikacji biznesowych) od najbardziej zachwalanych i pularnych języków i narzędzi RAD. Kupiłem licencję i pisałem programy to wiem o czym mówię. Ale to było przed dobą SQL i Internetem.

wb.

Przeczytałem trzy razy i nie załapałem Twojego posta (nie znajduję myśli przewodniej). Ale nie poddaję się, zjem obiad i spróbuję po raz kolejny.

@Waldemar: Również nie za bardzo mogę znaleźć myśl przewodnią w Twoim ostatnim poście. Domyślam się, że po prostu szukasz języka pomocniczego do Perla (tak jak napisałeś) i przyglądasz się Rubiemu stąd porównywanie i benchmarkowanie. Napiszę tylko, że Rubiemu do Perla całkiem niedaleko, Matz (twórca Rubiego) zaczęrpnął trochę z niego (trochę składni, trochę innych rzeczy np. magiczne zmienne globalne, regexpy) więc powinieneś szybko “się odnaleźć” w Rubim, jeśli zaczniesz go dogłębniej poznawać. Ja osobiście nie przepadam za “perlizmami” w Rubim - ale to kwestia gustu :slight_smile:

Przy okazji Redmine i benchmarków: Kirk Haines z Engineyard wyciągnął z niego 3000 reqs/s na zwykłym Rubinowym Webricku + caching reverse proxy opartym na Swiftiply - wszystko pisane w czystym Ruby - nie jest to super świeżość bo art. ma już chyba kilka miesięcy ale ciekawy bo pokazujący tak naprawdę zalety i dużą wagę przemyślanej strategii keszującej.

Waldemar: Szacun. Podniosłeś stwierdzenie „benchmarki kłamią” do nowego poziomu.