On je taky nesmysl nechavat si rozezrat Apache zevnitr pomoci mod_perlu/mod_ruby, kdyz existuje neco jako fastcgi :). To potom muze mit Apache napr. stovky procesu a tucna aplikace ma napr. jen pet.
FastCGI je navic podle mych praktickych testu rychlejsi nez mod_*.
Ale vyvoj temer umrel. Do konference prijdou tri maily za tyden.
Taky mi to prijde jako skoda a fastcgi se mi libi vic nez mod_* (uz jen kvuli 1 proces apache != 1 konexe na externi zdroje - databaze apod.).
Ale pri radove stovkach requestu se zacina chovat podivne a hrozne spatne se to ladi.
Zajímavý názor. Mám všechny požadavky řešené perlovými skripty, tedy neexistuje jiný požadavek v našem ISu, který by šel např. pro statická data (nemáme takové věci). Tudíž každý požadavek potřebuje db. Jak by mohl fastcgi snížit počet potřebných spojení do db proti mod_perlu? Vždyť sdílením by způsobil kolapci session v Oracle, problémy s transakcema apod. Takže jak mi tam ten fastcgi pomůže?
Výkonově je to 14 serverů, na každém z nich ve špičce kolem 400 spojení. Rád si nechám poradit.
FastCGI funguje jako takova proxy naruby. Samotne skripty jsou "za" apachem, ktery funguje k samotne komunikaci s klientem (predavani pozadavku ke skriptu a posilani odpovedi). Tim padem muze tech samotnych skriptu byt radove min nez procesu apache.
V idealnim pripade je reseni proxy+apache+mod_* dosti podobne apache+fastcgi.
Pro blizsi studium to je treba http://www.fastcgi.com/ :-)
