ACHTUNG. Das ist ein Archiv des alten forum.ruby-portal.de. Die aktuelle Mailingliste gibt es auf lists.ruby-lang.org/pipermail/ruby-de.

NOTICE. This is a ready-only copy of the old forum.ruby-portal.de. You can find the current mailing list at lists.ruby-lang.org/pipermail/ruby-de.

Die Programmiersprache Ruby

Blog|

Forum|

Wiki  


Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]

Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 07:05 
Offline
Schüler

Registriert: 14 Apr 2004, 18:04
Beiträge: 49
Wohnort: Berlin
mod_ruby lässt sich nicht in shared hosting umgebungen einsetzen
(auch wenn das ab und zu behauptet wird, es funkt nicht)

der ruby interpreter ist single threaded, also auf keinen fall das threading model vom apache 2.0 einsetzen.

ruby stürzt ab und zu doch ab.

der ruby garbage collector ist nicht geeignet für lange laufzeiten.

mod_ruby ist langsamer als Fast-CGI server (!!) Schwer zu glauben aber ganz eindeutig messbar.


Natürlich ist dies kein schlimmes Problem bei dedicated servern und bei Linux Hosts und bei korrekter Konfiguration die nur wenige Requests (~100) pro fork Instanz bedient.

Bei Fast-CGI sollte man sich auch überlegen ob man wirklich auf apache setzt, das modFastCGI ist nämlich deutlich eine Schwäche des Indianers

_________________
IDE's für Ruby, Python, PHP
www.scriptolutions.com
CTO Lothar Scholz


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 10:16 
Offline
Geselle

Registriert: 06 Okt 2004, 09:50
Beiträge: 157
Welche Möglichkeiten habe ich denn noch, wenn ich Ruby auf einem Webserver betreiben möchte?

Noch was anderes: Gibt es nicht mittlerweile auch sowas wie Just In Time Compiler für Ruby, um die Geschwindigkeit zu erhöhen, wenn man Anwendungen mit Ruby schreibt?

Gruß

Mike


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 12:02 
Offline
Schüler

Registriert: 30 Jun 2004, 10:26
Beiträge: 20
Wohnort: Frankfurt
llothar hat geschrieben:
....
der ruby garbage collector ist nicht geeignet für lange laufzeiten.
....
Natürlich ist dies kein schlimmes Problem bei dedicated servern und bei Linux Hosts und bei korrekter Konfiguration die nur wenige Requests (~100) pro fork Instanz bedient.

Kannst Du das etwas näher ausführen ?
Bei Apache als dedicated server ist mir das schon klar, da wird jeder apache Prozess alle paar hundert requests beendet, aber wie läuft das bei fastCGI ? Da muss doch der Ruby (oder was auch immer) Prozess wohl auch periodisch neugestartet werden, oder?

llothar hat geschrieben:
Bei Fast-CGI sollte man sich auch überlegen ob man wirklich auf apache setzt, das modFastCGI ist nämlich deutlich eine Schwäche des Indianers


Hm, da offenbar sogar die Spiegel-webseite unter apache/fastcgi betrieben wird, kann es ja wohl so schlecht nicht sein, oder ?

http://uptime.netcraft.com/up/graph/?ho ... spiegel.de

Gruss,

-klaus.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 15:28 
Offline
Meister

Registriert: 25 Jun 2002, 20:39
Beiträge: 276
Wohnort: Hamburg
klausm hat geschrieben:
Kannst Du das etwas näher ausführen ?
Bei Apache als dedicated server ist mir das schon klar, da wird jeder apache Prozess alle paar hundert requests beendet, aber wie läuft das bei fastCGI ? Da muss doch der Ruby (oder was auch immer) Prozess wohl auch periodisch neugestartet werden, oder?


Das ist ja gerade der Witz an FastCGI das du nur einmal einen ruby Prozess startest. Dein Programm sitzt sozusagend in einer Endlosschleife und schaut nach ob ein Request kommt.

Hier ein Perl Beispiel (hatte ich gerade zur Hand)


1
2
3
4
5
6
7
8
9
10
11
12
13
14

use FCGI; # Imports the library; required line
# Initialization code
$cnt = 0;
# Response loop
while (FCGI::accept >= 0) {
print "Content-type: text/html\r\n\r\n";
print "<head>\n<title>FastCGI Demo Page (perl)</title>\n</head>\n";
print "<h1>FastCGI Demo Page (perl)</h1>\n";
print "This is coming from a FastCGI server.\n<BR>\n";
print "Running on <EM>$ENV{SERVER_NAME}</EM> to <EM>$ENV{REMOTE_HOST}</EM>\n<BR>\n";
$cnt++;
print "This is connection number $cnt\n";
}

so oder so ähnlich geht das auch unter ruby.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 15:37 
Offline
Schüler

Registriert: 30 Jun 2004, 10:26
Beiträge: 20
Wohnort: Frankfurt
leobm hat geschrieben:
Das ist ja gerade der Witz an FastCGI das du nur einmal einen ruby Prozess startest. Dein Programm sitzt sozusagend in einer Endlosschleife und schaut nach ob ein Request kommt.


o.k., ich hatte auch schon mal mit FastCGI rumgespielt (mt CLisp) aber das ist schon eine Weile her ....... aber wie ist das nun mit besagtem Problem, dass Ruby eine angeblich schlechte GC-Implementierung hat? Dann muss man doch auch unter FastCGI den Ruby Prozess periodisch neu Starten, oder?

Gruss,

-klaus


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 17:14 
Offline
Rubyist
Benutzeravatar

Registriert: 09 Dez 2003, 23:05
Beiträge: 352
ist fastcgi frei im sinne von gpl oder bsd? soweit ich weiss nicht oder?


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Nov 2004, 18:32 
Offline
Ex-Admin
Benutzeravatar

Registriert: 12 Mai 2003, 18:49
Beiträge: 890
Wohnort: Kiel
Moin!

Also, frei ist das bestimmt, die FastCGI-Implementierung des Apachen steht ja sicher auch unter der Apache License, die ja frei und beinahe GPL-Kompatibel ist. Auch die drei Bibliotheken im RAA , die das unterstützen, stehen alle unter "Ruby's License", wobei ich immer noch weiß, was das überhaupt ist.

Ich denke schon, dass man sich da Speicherlecks programmieren kann, wenn der Prozess immer läuft (so genau kenne ich den GC von Ruby nicht), aber wenn man etwas aufpasst, sollte der GC doch alles erkennen und abräumen.

iGEL

_________________



# Kein Kommentar!!


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite Vorherige  1, 2

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach: