Wenn Änderungen in der Konfiguration von kivitendo gemacht werden, muss der Webserver neu gestartet werden.
Bei der Entwicklung für FastCGI ist auf ein paar Fallstricke zu achten. Dadurch, dass das Programm in einer Endlosschleife läuft, müssen folgende Aspekte beachtet werden.
Betrifft die Funktionen warn
,
die
, exit
,
carp
und confess
.
Fehler, die dass Programm normalerweise sofort beenden (fatale
Fehler), werden mit dem FastCGI Dispatcher abgefangen, um das Programm
am Laufen zu halten. Man kann mit die
,
confess
oder carp
Fehler
ausgeben, die dann vom Dispatcher angezeigt werden. Die kivitendo
eigene $::form-
error()> tut im Prinzip das
Gleiche, mit ein paar Extraoptionen. warn
und
exit
hingegen werden nicht abgefangen.
warn
wird direkt nach STDERR, also in Server Log
eine Nachricht schreiben (sofern in der Konfiguration nicht die
Warnungen in das kivitendo Log umgeleitet wurden), und
exit
wird die Ausführung beenden.
Prinzipiell ist es kein Beinbruch, wenn sich der Prozess
beendet, fcgi wird ihn sofort neu starten. Allerdings sollte das die
Ausnahme sein. Quintessenz: Bitte kein exit
benutzen, alle anderen Exceptionmechanismen sind ok.
Um zu vermeiden, dass Informationen von einem Request in einen
anderen gelangen, müssen alle globalen Variablen vor einem Request
sauber initialisiert werden. Das ist besonders wichtig im
$::cgi
und $::auth
Objekt, weil
diese nicht gelöscht werden pro Instanz, sondern persistent gehalten
werden.
In SL::Dispatcher
gibt es einen sauber
abgetrennten Block, der alle kanonischen globalen Variablen listet und
erklärt. Bitte keine anderen einführen ohne das sauber zu
dokumentieren.
Datenbankverbindungen wird noch ein Guide verfasst werden, wie man sicher geht, dass man die richtige erwischt.
Die kritischen Pfade des Programms sind die Belegmasken, und unter diesen ganz besonders die Verkaufsrechnungsmaske. Ein Aufruf der Rechnungsmaske in kivitendo 2.4.3 stable dauert auf einem Core2duo mit 4GB Arbeitsspeicher und Ubuntu 9.10 eine halbe Sekunde. In der 2.6.0 sind es je nach Menge der definierten Variablen 1-2s. Ab der Moose/Rose::DB Version sind es 5-6s.
Mit FastCGI ist die neuste Version auf 0,26 Sekunden selbst in den kritischen Pfaden, unter 0,15 sonst.
UTF-8 kodierte Installationen sind sehr anfällig gegen fehlerhfate Encodings unter FCGI. latin9 Installationen behandeln falsch kodierte Zeichen eher unwissend, und geben sie einfach weiter. UTF-8 verweigert bei fehlerhaften Programmpfaden kurzerhand das Ausliefern. Es wird noch daran gearbeitet, alle Fehler da zu beseitigen.