És mi van akkor…

…ha a monit egyáltalán nem vár az Apache leállításának kimenetére, hanem a “stop program” után egyből, ész nélkül megpróbálja ráindítani a “start program”-ot. Ha a stop program még nem fejeződött be (ami szarrá terhelt Apache esetében meglehetősen valószínű: eltart pár másodpercig, míg normálisan le tudnak állni a forkolt php-k, a fastcgi processz, az Apache childok), ez féllábú Apache indítást fog eredményezni: a processzek ott vannak, de nem válaszolnak (mert ilyet láttunk már sokat), az indítás tulajdonképpen sikertelen — és a kedves extrák: az elfogyott szemaforok, meg persze a (jogosan felháborodott) felhasználók…

Ha ez így van (ami persze nagy bénaság lenne a monit részéről), akkor a megoldás egyszerű: a start program lecserélése valami olyan megoldásra, ami ellenőrzi, és kigyilkolja az esetlegesen futó/beragadt processzeket.

CM gyorsítósáv: Apache -> LigHTTPd az alleycat.hu és a criticalmass.hu alatt.

A criticalmass.hu (és az alleycat.hu) gyorsításának második lépése az Apache kiváltása valami rendes webszerverrel. (Tegnapi Homár-levél után szükségszerű.)

Az eddigi setup egy Apache 1.3 virtualhostokkal, és minden modullal, ami egy szolgáltatásban adott virtual host környezetben szükséges. (Az sok.)

Ezt első körben lecsere Apache 2-re, mod_php4, mod_proxy, mod_rewrite modulokkal. (Az pont annyi, amennyi kell.) Ezen kívül régi szerelmem, a LigHTTPd felkerült újra a 8080-as portra, kezdetben kizárólag simple-vhost modullal. (Erre ugyebár azért van szükség, mert 2 siteot szolgált ki.)

Az Apache 2 figyelt a bringás siteok 80-as portján és egy rafkós rewrite szabállyal a statikus kéréseket továbbdobta a 8080-as porton figyelő Lighty-nak.

Na ez nem működött. A terhelés nem csökkent számottevően, az Apache 2 tényleg olyan tetűlassú, mint amilyennek hírlik. A statikus tartalmat lehet, hogy simán érdemes lett volna Apache 2-vel kiszolgálni, de az alapvető probléma az Apache 2 processzek által támasztott CPU terhelés volt még akkor is, amikor az összes child processzt induláskor forkoltam le, és egy child 4096 kérést szolgálhatott ki.

Maradt az, hogy a Lighty figyeljen kizárólag a 80-as porton. Ez (tapasztalat) kb. ötödére csökkenti a loadot, gyors, mint Magwas kéccáhon, cserébe nem parsolja a .htaccess fileokat, statikusan kell megadni a configban a rewrite szabályokat — ráadásul a szintaktika is más, mint az Apache-oknál.

A jelenlegi rewrite szabályok:

url.rewrite-final = (
"^/system/test/(.*)$" => "/index.php?q=system/test/$1",
"^/([^.?]*)?(.*)$" => "/index.php?q=$1&$2",
"^/([^.?]*)$" => "/index.php?q=$1",
"^/search/node/(.*)$" => "/index.php?q=search/node/$1",
"^/rss.xml$" => "/index.php?q=rss.xml"
)

Ezzel a jelek szerint pattan mind a két site, de persze szólj, ha találsz valami hibát.

A PHP futtatásához bekerült még egy fastcgi modul a Lightyba, a PHP cgi-ként fut, 2 processzben, processzenként 4 child processzel. (Default beállításként 10000 request per child.)

Php-cgi fine tuning még hátravan, egyelőre a 8 megás memórialimitet nyomtam fel 32 megára, mert a Drupalnak ennyi általában kell.

Ha rewrite-ből adódó hiba merül fel, írj. Ha bármilyen más hiba merül fel, írj. Lipilee ezen a domainen.

Update: Két benchmark: itt és itt.