A co gdyby napisać demona w PHP, który potrafiłby przyjmować żądania z klienta FastCgi, przekazać je do zainicjalizowanego już kontrolera (patrz MVC) odebrać wynik i odesłać? Pomysł fajny - odpada konieczność wielokrotnej uruchamiania, kompilacji kodu, inkludowania plików, bo przecież aplikacja cały czas działa. Odpada konieczność konstruowania klas, populowania w nich danych dla każdego żądania - wystarczy zrobić to raz, podczas uruchomienia.

Tak mi się ten pomysł spodobał, że postanowiłem się przekonać, czy to ma szanse zadziałać. Google? Cóż, nikt chyba wcześniej nie wpadł na taki pomysł, ponieważ nie znalazłem niczego konkretnego. Zacząłem zatem od specyfikacji protokołu FastCgi. Sam protokół do najprostszych nie należy, nie mniej jednak w implementacji serwera pomogła mi implementacja klienta stworzona na potrzeby aplikacji Nanoweb - The PHP Web Server. Dodatkowo posłużyłem się funkcjonalnością PCNTL w celu implementacji wielowątkowości.

Testowa aplikacja działała na zasadzie utworzenia nasłuchującego na porcie TCP socketa, w momencie nadejścia połączenia wersja 1) odsyłała odpowiedź, zamykała połaczenie z klientem i była gotowa do obsługi następnych wersja 2) dla każdego żądania tworzyła nowy wątek. Obie wersje, oraz skrypt referencyjny odpowiadały zawartością phpinfo().

Problemy jakie napotkałem po drodze:

• problem z parsowaniem ramek FCGI_PARAMS - one są osadzane w standardowej ramce FastCgi, ale mają chyba krótszy niż 8 bajtów nagłówek, postanowiłem całkowicie je zignorować, nie mniej jednak od ich poprawnego sparsowania zależy czy w aplikacji pojawi się tablica $_SERVER, $_GET i $_POST
• trzeba samodzielnie zaimplementować cały mechanizm dekodowania formularzy jak i plików z żądania POST
• zmienne pomiędzy procesami utworzonymi via pcntl_fork() kopiują się, nie są referencjami, dlatego w wątku potomnym możemy odczytać wartość zmiennej, ale zmiana nie jest widoczna dla innych wątków. Nie dotyczy to oczywiście zmiennych typu resource.

Kiedy udało mi się już zaimplementować podstawowe minimum: demon potrafi odesłać prawidłową odpowiedź: przystąpiłem do benchmarkowania.

Wyniki mnie rozwaliły. Pierwsze referencyjny benchmark dla standardowej konfiguracji: apacz + php.fcgi -b 127.0.0.1:80800 + skrypt

[pink@poema ~]$ ab -n 100 -c 5 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        57346 bytes
 
Concurrency Level:      5
Time taken for tests:   0.859 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      5750300 bytes
HTML transferred:       5734600 bytes
Requests per second:    116.39 [#/sec] (mean)
Time per request:       42.960 [ms] (mean)
Time per request:       8.592 [ms] (mean, across all concurrent requests)
Transfer rate:          6535.76 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       3
Processing:    13   42   4.2     43      48
Waiting:        7   36   4.3     38      42
Total:         13   42   4.1     43      48
 
Percentage of the requests served within a certain time (ms)
  50%     43
  66%     43
  75%     43
  80%     43
  90%     44
  95%     44
  98%     44
  99%     48
 100%     48 (longest request)

Drugi wynik apacz + przygotowanego servera FastCGI bez forkowania, co oznacza, że każde żądanie przetwarzane jest pojedynczo:

[pink@poema ~]$ ab -n 100 -c 5 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        23082 bytes
 
Concurrency Level:      5
Time taken for tests:   0.622 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2323900 bytes
HTML transferred:       2308200 bytes
Requests per second:    160.84 [#/sec] (mean)
Time per request:       31.088 [ms] (mean)
Time per request:       6.218 [ms] (mean, across all concurrent requests)
Transfer rate:          3650.07 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       5
Processing:     9   30   8.3     28      60
Waiting:        9   29   8.5     26      59
Total:          9   30   8.2     28      60
 
Percentage of the requests served within a certain time (ms)
  50%     28
  66%     30
  75%     33
  80%     35
  90%     38
  95%     56
  98%     58
  99%     60
 100%     60 (longest request)

Czas o parę procent krótszy dla zwykłego phpinfo(). W przypadku inicjalizacji połączeń z bazami, memcache, odczytywania identycznych zestawów danych (ustawień) ta różnica może być o wiele większa. Przy czym pojawia się tu jeden problem: im więcej równoczesnych żądań (parametr -c dla ab) tym wynik jest gorszy i zbliża się do tego poniżej. Oba benchmarki, referencyjny jak i testowy obsługiwane były przez pojedynczy backend FastCgi, przy czym ten w referencyjnej konfiguracji radzi sobie lepiej ze współbieżnymi żądaniami. Należy zadbać tutaj o odpowiednie parametry dla socket_listen() ponieważ zbyt mały backlog powoduje, iż połączenia współbieżne się kolejkują. Przy odpowiednio dużej wartości $backlog problem nie występuje.

[pink@poema ~]$ ab -n 100 -c 5 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        23047 bytes
 
Concurrency Level:      5
Time taken for tests:   3.327 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2320400 bytes
HTML transferred:       2304700 bytes
Requests per second:    30.05 [#/sec] (mean)
Time per request:       166.372 [ms] (mean)
Time per request:       33.274 [ms] (mean, across all concurrent requests)
Transfer rate:          681.01 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.9      0       7
Processing:    11  165  62.5    166     391
Waiting:        8  132  60.7    129     288
Total:         11  165  62.3    166     391
 
Percentage of the requests served within a certain time (ms)
  50%    166
  66%    189
  75%    204
  80%    209
  90%    236
  95%    270
  98%    337
  99%    391
 100%    391 (longest request)

Jak łatwo zauważyć w tym przypadku wyniki są kilkanaście razy gorsze. Przypuszczam, że wynika to z niewydolności forkowania w PHP.

Konkludując: idea wygląda wielce obiecująco i wydaje mi się, że jeśli by rozwiązać jakoś problem spadku wydajności przy konkurencyjnych żądaniach (forkowanie skreślam całkowicie, wyniki mówią same za siebie) poprzez uruchomienie większej ilości instancji demona i rozproszoną dystrybucję żądań CGI można by osiągnąć całkiem przyzwoite wyniki. Dalszą poprawę wydajności jak i redundancję systemu można osiągnąć poprzez uruchomienie klastra serwletów i balansowanie ruchu apacz, klient fCGI ->serwlet z użyciem HAProxy (przetestowałem, z metodą balansowania round-robin, wyniki niżej)

Niestety inną sprawą jest stabilność takiego rozwiązania. PHP nie jest zaprojektowany do pracy w trybie demona i prawdopodobnie mogą pojawić się problemy z garbage collectorem lub wyciekami pamięci. Dodatkowo pisanie aplikacji serwletowych wymaga nieco innego podejścia do samej architektury - nie można sobie pozwolić na radosne używanie miliona zmiennych bez zawracania sobie głowy zwalnianiem pamięci, ponieważ trzeba mieć na uwadze, iż po zakończeniu żądania zaalokowana pamięć nie zostanie zwolniona samodzielnie. Dodatkowo zmienia się także koncepcja deployowania aplikacji, ponieważ każda zmiana kodu wymaga restartu całego klastra serwletów.

Update: wyniki z użyciem 3 wątków php.fcgi -b 127.0.0.1:8061, php.fcgi -b 127.0.0.1:8062, php.fcgi -b 127.0.0.1:8063 + haproxy z balansowaniem round-robin:

[pink@poema php cgi server]$ ab -n 100 -c 15 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        57373 bytes
 
Concurrency Level:      15
Time taken for tests:   0.535 seconds
Complete requests:      100
Failed requests:        33
   (Connect: 0, Receive: 0, Length: 33, Exceptions: 0)
Write errors:           0
Total transferred:      5754584 bytes
HTML transferred:       5738884 bytes
Requests per second:    186.75 [#/sec] (mean)
Time per request:       80.323 [ms] (mean)
Time per request:       5.355 [ms] (mean, across all concurrent requests)
Transfer rate:          10494.54 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5   9.6      0      31
Processing:    24   70  24.0     68     117
Waiting:        6   57  25.4     55     106
Total:         30   75  22.6     77     117
 
Percentage of the requests served within a certain time (ms)
  50%     77
  66%     85
  75%     90
  80%     95
  90%    110
  95%    112
  98%    115
  99%    117
 100%    117 (longest request)

Wyniki z użyciem 3 instancji serwletu + haproxy z balansowaniem round-robin:

[pink@poema php cgi server]$ ab -n 100 -c 15 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        23173 bytes
 
Concurrency Level:      15
Time taken for tests:   0.479 seconds
Complete requests:      100
Failed requests:        67
   (Connect: 0, Receive: 0, Length: 67, Exceptions: 0)
Write errors:           0
Total transferred:      2329784 bytes
HTML transferred:       2314084 bytes
Requests per second:    208.65 [#/sec] (mean)
Time per request:       71.891 [ms] (mean)
Time per request:       4.793 [ms] (mean, across all concurrent requests)
Transfer rate:          4747.12 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   5.1      0      21
Processing:     9   64  45.3     49     180
Waiting:        2   61  45.0     46     179
Total:          9   66  44.8     52     180
 
Percentage of the requests served within a certain time (ms)
  50%     52
  66%     60
  75%     85
  80%    105
  90%    148
  95%    166
  98%    180
  99%    180
 100%    180 (longest request)

Jak widać wyniki serwletu nadal lepsze i zapewne jak w poprzednim przypadku róznica może powiększyć się parokrotnie przy kodzie wymagającym inicjalizacji stałych elementów (konfig, includy klas).

Update: wyniki z jednym watkiem serwletu, ale za to z nieco bardziej złożoną aplikacją: klasa, która w konstruktorze tworzy jedno połaczenie do memcache, jedno połaczenie z bazą danych i robi prepare zapytania SQL, i dalej we właściwej metodzie run() podbija wartość klucza memcache i wykonuje przygotowane wcześniej zapytanie.

Test php.cli -b 127.0.0.1:8060, klasa inicjalizowana i uruchamiana w pojedynczym pliku index.php

[pink@poema var]$ ab -n 100 -c 10 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        1990 bytes
 
Concurrency Level:      10
Time taken for tests:   0.483 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      214700 bytes
HTML transferred:       199000 bytes
Requests per second:    207.17 [#/sec] (mean)
Time per request:       48.270 [ms] (mean)
Time per request:       4.827 [ms] (mean, across all concurrent requests)
Transfer rate:          434.36 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.2      0       5
Processing:    12   46   6.6     48      60
Waiting:       11   45   6.6     47      60
Total:         13   46   6.4     48      65
 
Percentage of the requests served within a certain time (ms)
  50%     48
  66%     48
  75%     49
  80%     49
  90%     50
  95%     50
  98%     59
  99%     65
 100%     65 (longest request)

Test serwletu, klasa inicjalizowana przed otwarciem portu TCP, połączenie klienckie wykonuje metodę run() na zainicjalizowanej już klasie:

[pink@poema var]$ ab -n 100 -c 10 http://stateless.projekt.kurylowicz.info/
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 stateless.projekt.kurylowicz.info (be patient).....done
 
Server Software:        Apache/2.2.14
Server Hostname:        stateless.projekt.kurylowicz.info
Server Port:            80
 
Document Path:          /
Document Length:        1994 bytes
 
Concurrency Level:      10
Time taken for tests:   0.245 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      215100 bytes
HTML transferred:       199400 bytes
Requests per second:    407.70 [#/sec] (mean)
Time per request:       24.528 [ms] (mean)
Time per request:       2.453 [ms] (mean, across all concurrent requests)
Transfer rate:          856.41 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   2.5      0      13
Processing:     8   22   7.0     22      42
Waiting:        5   21   7.3     20      41
Total:          8   24   7.0     23      43
 
Percentage of the requests served within a certain time (ms)
  50%     23
  66%     25
  75%     28
  80%     31
  90%     33
  95%     37
  98%     41
  99%     43
 100%     43 (longest request)

Jak widac z dwóch powyższych testów średni czas przetwarzania pojedynczego żadania przez serwlet jest 50% krótszy.

Mijający już weekend upłynął mi pod znakiem migracji serwera www.poema.art.pl na FastCgi. Sporo alternatyw, sporo, ale niepełnych informacji - trudno się w tym połapać komuś, kto nie jest zaznajomiony z tą technologią. Ale od początku. Dlaczego warto się przerzucić  na FastCgi? Otóż powody są co najmniej dwa:

1. wydajność
2. bezpieczeństwo

Rozwinięcie wątku wydajności należałoby zacząć od wyjaśnienia w jaki sposób FastCgi działa. Otóż dzięki FastCgi separujemy wykonanie kodu PHP od wątków Apacza. Apacz w modelu FastCgi służy wyłącznie do komunikacji z przeglądarką klienta. W momencie kiedy klient zażąda uruchomienia skryptu PHP - żądanie to przekazywane jest do 'serwera FastCGI' który używając interpretera PHP uruchamia skrypt i odsyła wynik do Apacza. Wygląda to mniej więcej tak:

+----------+  TCP 80  +----------+ Unix socket
|  Klient  | <----->  |  Apache  | <-----+
+----------+          +----------+       |
                       user: http        |
+----------+          +----------+       |      +-------------+        +--------------+
|  Klient  | <----->  |  Apache  | <-----+----> | PHP FastCgi | <----> | Server MySQL |
+----------+          +----------+       |      +-------------+        +--------------+
                       user: http        |        user: john
+----------+          +----------+       |
|  Klient  | <----->  |  Apache  | <-----+
+----------+          +----------+
                       user: http

Przy użyciu spawn-fastcgi uruchamiamy dla każdego z użytkowników własny serwer PHP FastCgi który nasłuchuje na Unixowym sockecie. Apache komunikuje się po sockecie z wybranym zgodnie z ustawieniami (per vhost) serwerem żądając wykonania skryptu. Dzięki temu otrzymujemy izolację wątków PHP od wątków Apache. Dodatkowo PHP FastCgi działając z uprawnieniami użytkownika, nie zaś serwera Apache ma możliwość zapisu do katalogów użytkownika, a także ograniczenia odczytu plików do których posiada uprawnienia.

Ok, ale co z wydajnością?

Po pierwsze Apache, dzięki temu że nie parsuje w każdym swoim wątku PHP zabiera o wiele mniej pamięci. Przy dużej ilości żądań jest  to sprawa kluczowa. Dzięki modelowi FastCgi można w prawidłowy sposób wykorzystać mechanizm database persistent connections (eg. w MySQL). W przypadku wielu wątków Apacza parsujących PHP nawiązywanych jest tyle połączeń ile wątków. Nowe wątki nie potrafią użyć ponownie połączeń utworzonych przez zabite wątki. Dzięki temu w parę minut osiągamy maksymalny limit połączeń z bazą.  W przypadku FastCgi nawiązanych zostaje tyle połączeń ile wątków i połączenia te są cały czas utrzymywane. To jest także sprawa kluczowa dla serwisów o wysokim obciążeniu.

Bezpieczeństwo?

Wspomniałem wcześniej - wykonanie kodu PHP z uprawnieniami użytkownika. Ale nie tylko - separacja cache APC to kolejny element bezpieczeństwa. Dalej: możliwość pozbycia się safe mode w PHP - aktualnie to mechanizm z którego PHP się wycofuje. W wersji 5 ma już go nie być.

fCgi, FastCgi, fCgid?

Jest sporo zamieszania jeśli chodzi o mechanizm FastCgi. Istnieje mnóstwo alternatyw. Osoba zaznajamiająca się z tematem za pomocą poldek search *cgi*   może czyć się nieco zagubiona. Dlatego opiszę co potrzebujemy aby to wszystko właściwie uruchomić.

Zacznijmy od końca, czyli od PHP. Potrzebna będzie paczka zawierająca interpreter fcgi dla PHP - jest to dodatkowy moduł SAPI (oprócz eg. zwyczajnego cli, lub modułu do Apacha) które można skompilować, tudzież zainstalować. Pod PLD jest to pakiet "php-fcgi". Dalej, przyda się coś co będzie potrafiło utworzyć nam serwery FastCgi dla użytkowników. Pakiet "spawn-fcgi" jest całkiem dobry do tego. I wreszcie musimy nauczyć Apache komunikować się z naszymi serwerami. Doinstalujmy moduł "apache-mod_fastcgi".

Wszystkie moduły można bez obaw zainstalować na serwerze który używa modułu "apache-mod_php"  do parsowania kodu PHP. Generalnie można używać obu modeli parsowania jednocześnie - część vhostów i aplikacji parsować modułem Apacza, najbardziej obciążone vhosty puścić przez FastCgi.

Konfiguracja PHP

Nieco problematyczną sprawą w modelu FastCgi jest  konfiguracja PHP per vhost. Nie możemy do tego użyć ani plików .htacess ani dyrektyw php_flag w konfiguracji vhosta. Należy dla każdego z vhostów wymagającego niestandardowego konfigu utworzyć osobny php.ini. Ma to jedną zasadniczą wadę. /etc/php/php.ini który zawiera nasze istawienia PHP nie będzie czytany. Zatem dla każdego z vhostów należy mieć kopię php.ini zawierającą wsztstkie opcje konfiguracyjne które chcemy zmienić. Jeśli którejś z opcji nie ujmiemy w indywidualnym .ini będzie ona miała wartość domyślną, taką, jaka jest wkompilowana w php. Czytany jest za to katalog /etc/php/conf.d, przy czym każda zdefiniowana tam opcja konfiguracyjna nadpisuje tę zdefiniowaną w indywidualnym .ini.

W PHP 5 ma być możliwość używania w globalnym php.ini wpisów [myhost.com], dzięki czemu będzie można nadpisać globalne ustawienia per vhost. Niestety póki co, trzeba robić kopie globalnego php.ini i zmieniać w niej wybrane opcje. Minimalna postać indywidualnego php.ini, tak, aby zachować najważniejsze spersonalizowane dla dystrybucji ustawienia to:

; Safe mode w binarce PHP domyślnie jest on, więc jeśli serwis
; pod nim nie działa trzeba wyłączyć
safe_mode = Off
; To warto podać, ograniczymy możliwość otwierania cudzych katalogów
open_basedir = "/home/webhosts/www.mychost.pl:/home/services/httpd:/tmp"
include_path = ${open_basedir}
error_reporting  =  E_ALL & ~E_NOTICE & ~E_STRICT
display_errors = Off
log_errors = On
; Błedy do sysloga, to php będzie działało z prawami usera, więc nie
; można zapisywać błędów do wspólnego pliku
error_log = syslog
ignore_repeated_errors = On
html_errors = Off
upload_tmp_dir = "/tmp"
expose_php = Off
memory_limit = 32M
date.timezone = "Europe/Warsaw"
browscap = /etc/php/browscap.ini

Konfiguracja spawn-fastcgi

Tu sprawa jest dość prosta, otóż spawn-fastcgi nie ma żadych konfigów, a wszystkie parametry przekazujemy w linii poleceń.

spawn-fcgi -s /var/run/fastcgi/fcgi.myhost.sock -M 0660 \
  -P /var/run/fastcgi/fcgi.myhost.pid -U http -G http \
  -u 10012 -g 10012 -C 2 -- /usr/sbin/php.fcgi -c /etc/php/webapps.d/myhost.ini

Po kolei: -s  /var/run/fastcgi/fcgi.myhost.sock mówi w którym miejscu tworzyć sockety serwerów FastCgi. Ja wybrałem sobie katalog /var/run/fastcgi. Należy go utworzyć nadając prawo do zapisu użytkownikowi, z którego prawami będzie działał serwer oraz prawa do odczytu dla serwera Apache (user http). -M 0660 każe zmienić uprawnienia do utworzonego socketa na 660, -P /var/run/fastcgi/fcgi.myhost.pid mówi gdzie zapisujemy plik z PIDem serwera. Parametry -U http -G http są ważne, i mówią że prawa dostępu do socketa mają być nadane dla użytkownika http. Jako że z socketa będzie korzystał serwer Apache zmiana uprawnień jest konieczna. Dalej -u 10012 -g 10012 - tutaj definiujemy id (bądź nazwę) użytkownika i grupy z uprawnieniami którego ma działać FastCgi. Z uprawnieniami tego użytkownika będzie wykonany kod PHP.  Można tu użyć ID'ów użytkowników wirtualnych. Nie muszą być dodani do /etc/passwd. Idealnie to się wpisuje w model hostingu gdzie użytkowników trzymamy w bazie danych bazie danych. Ważną sprawą jest jedynie, aby wirtualny użytkownik miał prawa do zapisu do katalogu na który wskazuje parametr -s. Można mu nadać prawa 777 lub trzymać sockety w katalogach domowych użytkowników.  -C 2 określa ile instancji FastCgi ma zostać uruchomionych. Wartość trzeba dobrać doświadczalnie. W przypadku zbyt małej ilości Apache będzie podawał klientom bład 500. I wreszcie pora na interpreter: -- /usr/sbin/php.fcgi -c /etc/php/webapps.d/myhost.ini - używamy zainstalowanego wcześniej php-fgi - podając mu parametr -c z indywidualnym plikiem konfiguracyjnym. Jeśli nie podamy parametru -c zostanie użyty domyślny /etc/php/php.ini.

Jeden serwer FastCgi może obsługiwać wiele hostów wirtualnych. W najprostszym przypadku  można uruchomić jedną instancję serwera na prawach użytkownika mającego prawa do odczyty dla plików PHP (może to być http) i uruchomić na nim wszystkie nasze vhosty. Przy czym w oczywisty sposób pozbywamy się w takim przypadku korzyści płynących z separacji uprawnień. Przy hostingu wirtualnym lepiej przyjąć strategię: jedna instancja per 1 użytkownik na której odpalamy wszystkie jego vhosty.

W ogóle fajnie jest napisać sobie jakiś rc.skrypt, który będzie uruchamiał wszystkie zdefiniowane instancje podczas startu, pozwoli nam je zresetować, zatrzymać, etc.

Konfiguracja Apache

Ok, i teraz Apacz. Wszystko co zostało zrobione do tej pory można bez obaw robić na serwerze który obsługuje PHP via moduł Apacza. Operacje poniżej wymagają już zmiany w konfiguracji serwera WWW, a co za tym idzie są ryzykowne. Główne ryzyko, przy pomyłce w konfiguracji to możliwość zaserwowania niesparsowanych skryptów PHP, tak więc na działających serwerach polecam blokadę dostępu dla virtualki via Order deny, allow Allow from my.ad.re.ss Deny from all. Dodatkowo jak wspomniałem wcześnej model parsowania PHP via moduł jak i FastCgi może współistnieć jednocześnie, tak więc możemy przerzucać na FastCgi pojedyncze virtualki.

Ok, zaczynamy od pliku "/etc/httpd/conf.d/90_mod_fastcgi.conf" . Domyślnie jest tam jedynie linijka ładująca moduł fastcgi. Dopiszmy do pliku:

<IfModule mod_fastcgi.c>
  # Domyślne ustawienia serwera FastCgi, -pass-header Authorization jest bardzo ważne
  FastCgiConfig -idle-timeout 20 -maxClassProcesses 1 -pass-header Authorization
  # Zarejestrujmy dwie akcje
  Action php5-fcgi /php-cgi
  Action application/x-fcgi-php /php-cgi
  # Załóżmy że nasz serwer FastCgi będzie znajdował pod wirtualnym adresem /php-cgi
  <Location "/php-cgi">
    php_flag engine off
    Order Deny,Allow
    Deny from All
    Allow from env=REDIRECT_STATUS
    Options ExecCGI FollowSymLinks
    SetHandler fastcgi-script
  </Location>
</IfModule>

Ok, to wystarczy, żeby móc przystąpić do konfigurowania vhostów. Do vhosta, dla którego uruchomiona została już instancja spawn-fcgi i mamy utworzony socket w katalogu /var/run/fastcgi/fcgi.myhost.sock dopiszmy:

<VirtualHost www.myhost.pl:80>
[...]
<IfModule mod_fastcgi.c>
# Tak! wyłączamy engine PHP, dzięki temu moduł PHP, który
# cały czas działa zostawi pliki PHP tej wirtualki w spokoju
php_flag engine off
# Magic! Nadpisujemy handler application/x-httpd-php każąc wszystkim
# plikom php zdefiniowany wcześniej dla modułu zostać sparsowanym via FastCgi
Action application/x-httpd-php /php-cgi
# Definicja serwera, ścieżka musi być taka sama jak doc_root vhosta + /php-cgi
# Nie należy się przejmować faktem, iż /php-cgi nie istnieje w tej ścieżce, tak ma być!
FastCgiExternalServer /home/webhosts/myhost/php-cgi -socket /var/run/fastcgi/fcgi.myhost.sock
</IfModule>
</VirtualHost>

Jeśli mamy jakiekolwiek opcje konfiguracyjne dla php (php_flag, php_admin_value) to należy je usunąć.

Uruchamiamy!

Checklist:

• Sprawdzamy czy  instancja serwera FastCgi uruchomiona przez spawn-cgi działa: ps aux | grep cgi:

  10008   7832  0.0  1.6  71324 34212 ? SN   14:19   0:18 /usr/bin/php.fcgi -c /etc/php/webapps.d/myhost.ini
  10008   7833  0.0  1.4  67408 29276 ? SN   14:19   0:19 /usr/bin/php.fcgi -c /etc/php/webapps.d/myhost.ini
  http   15808  0.0  0.5  72288 11548 ? SN   20:11   0:00 /usr/sbin/fcgi-pm

• Sprawdzamy czy jest socket i czy http ma możliwośc odczytu: ls -la /var/run/fastcgi:

  -rw-r--r--  1 root root    4 09-20 14:19 fcgi.myhost.pid
  srw-rw----  1 http http    0 09-20 14:19 fcgi.myhost.sock

• Sprawdzamy, czy w naszym konfigu apacza nie ma błedów: service httpd configtest

Pora na restart Apache. Po tym kod PHP dla konfigurowanego vhosta powinien być parsowany via FastCgi, co będzie sygnalozowane w wyniku funkcji phpini() wpisem Server API CGI/FastCGI.

Dla kodu parsowanego via moduł Apache Server API  to Apache Handler.