Fastcgi інтерфейс

Це має на увазі що FastCGI програми запущені з Apache web-сервером також запустяться з lighttpd і навпаки.

FastCGI ліквідує безліч обмежень CGI програм. Проблема CGI програм в тому що вони повинні бути перезапущена web-сервером при кожному запиті, що призводить до зниження продуктивності.

FastCGI прибирає це обмеження зберігаючи процес запущеним і передаючи запити цьому постійно запущеному процесу. Це дозволяє не витрачати час на створення (fork ()) нових процесів.

Поки CGI програми з'єднані з сервером через pipe'и, FastCGI процеси використовують Unix-Domain-Sockets або TCP / IP для зв'язку з сервером. Це дає наступне перевагу над звичайними CGI програмами: FastCGI програми можуть бути запущені не тільки на цьому ж сервері, але і де завгодно в мережі

lighttpd включає в себе внутренний FastCGI розподільник навантаження який може використовуватися для розподілу відразу на кілька FastCGI серверів. На відміну від інших рішень тільки FastCGI процес повинен знаходитися в кластері, а не цілий web-сервер. Це дозволяє використовувати FastCGI процесу більше резурсов ніж, наприклад, load-balancer + apache + mod_php.

Якщо ви порівняєте FastCGI з apache + mod_php ви повинні звернути увагу на те, що FastCGI забезпечує додаткову безпеку, як запустити FastCGI процесу під користувачем відмінним від користувача web-сервера, а також може знаходитися в chroot'е відмінним від chroot'а web-сервера .

Підтримка FastCGI в lighttod надається через модуль fastcgi (mod_fastcgi) який має 2 опції в файлі конфігурації:

fastcgi.debug значення від 0 до 65535 для виставлення рівня налагодження в FastCGI модулі. На даний момент використовуються тільки 0 або 1. Виставите 1 щоб включити налагодження, і 0 щоб вимкнути. fastcgi.server

повідомляє модулю куди треба відправляти FastCGI виклики. кожне розширення файлу може відправляти свого власного FastCGI сервера. Балансування навантаження реалізується зазначенням декількох FastCGI сервером для одного розширення.

структура fastcgi.server секції:

розширення файлу або префікс (якщо починається з "/")

режим FastCGI протоколу. За замовчуванням це "responder", також є режим "authorizer".

опціонально і може бути включено "enable" (за замовчуванням) або "disable". Якщо включено то сервер спочатку перевіряє файл в локальному server.document-root каталозі і повертає 404 (Not Found) якщо такого файлу немає. Якщо вимкнено, то сервер перенаправляє запит до FastCGI інтерфейсу без цієї перевірки.

Якщо вказана bin-path:

Множинні розширення для того ж хоста

Приклад з префіксом:

Приклад для режиму "authorizer":

Зауважте що якщо "docroot" визначена, тоді її значення буде використано в змінних DOCUMENT_ROOT і SCRIPT_FILENAME FastCGI сервера.

FastCGI plugin надає автоматичний розподіл навантаження між декількома FastCGI серверами.

Щоб зрозуміти як працює розподіл навантаження ви можете включити опцію fastcgi.debug і отримати висновок подібний цьому:

Даний висновок показує безліч породеній FastCGI на локальній машині. Наступне пояснення вірно також і для віддалених з'єднань.

IP, порт, unix-socket (в даному випадку порожньо)
is-local, показник (0 - не виставлено, 1 - запущено.)
активні сполуки (завантаження)
PID

Як ви можете бачити список весь час впорядкований по полю загрузукі

При запиті нового соеденения, вибирається перший покажчик на FastCGI процес (один з найменшим навантаженням), значення завантаження збільшується на 1 (got proc.) І список сортується знову.

Якщо FastCGI запит закінчується або з'єднання обривається, завантаження FastCGI proc зменшується на 1 і список знову сортується (release proc.)

Така поведінка займає мало коду, вельми ефективно, і дозволяє використовувати fastcgi-сервера равнозагруженно, навіть якщо вони мають різні CPU.

Починаючи з 1.3.8 lighttpd може створювати просцесси за запитом якщо визначена bin-path, і FastCGI процеси запускаються локально.

Якщо ви хочете мати запущеним принаймні один FastCGI процес і більше при запитах, ви можете використовувати min-procs і max-procs.

Новий процес запускається як тільки середня кількість запитів очікують обробку одним процесом перевищить max-load-per-proc.

Параметр idle-timeout визначає як довго fastcgi-процес повинен очікувати новий запит перш ніж завішені свою роботу

Adaptive Spawning все ще нова можливість, і може вести себе нестабільно. Тут вказані кілька можливостей як контролювати створення нових процесів:

"Max-load-per-proc" => 1 якщо це працює у вас то все добре.

Якщо не виставлено min-procs == max-procs.

Для PHP ви також можете використовувати:

Це створить один socket і дозволить PHP самому створити 384 процесу.

Якщо ви не хочете дозволяти lighttpd управляти fastcgi процесами, приберіть bin-path і використовуйте spawn-fcgi щоб FastCGI створював процеси сам

Якщо у вас вже є працюючий PHP на web-сервері, виконайте короткий скрипт який просто містить

і подивіться на рядки містять виклик configure. Ви можете використовувати їх як основи для компіляції.

Ви повинні видалити опції --with-apxs. --with-apxs2 і ті які використовуються для компіляції з підтримкою Apache. Додайте наступні три опції для компіляції PHP з підтримкою FastCGI:

Після компіляції і інстраляціі перевірте що ваш PHP підтримує FastCGI, виконавши:

Зверніть увагу на (cgi-fcgi).

Важливо щоб php.ini містив:

В іншому випадку PHP_SELF не прийме правильне значення.

Починаючи з версії 1.3.6 lighttpd може сам створювати FastCGI процеси якщо необхідно:

PHP надає 2 спеціальні змінні оточення які контролюють число робочих запущених процесів під контролери одного наглядової процесу (PHP_FCGI_CHILDREN) і число запитів які один робочий процес обробить до завершення.

Щоб поліпшити безпеку запущених процесів ви тільки повинні передати необхідні змінні оточення FastCGI процесу.

Створення процесу FastCGI прямо в web-сервері має такі недоліки

процес FastCGI може бути запущений тільки локально
має тобі права що і web-сервер
має ту ж саму base-dir що і web-сервер

Як тільки ви почнете використовувати окремий FastCGI сервер щоб зняти навантаження з web-сервера, ви зможете контролювати процес FastCGI зовнішніми програмами, такими як spawn-fcgi.

spawn-fcgi використовується щоб запустити FastCGI процес в своєму оточенні, виставити йому user-id, group-id і змінити кореневу директорію (chroot).

Для більшої зручності повинен бути іспользвать wrapper скрипт бере на себе турботу про всі опціях. Такий скрипт включений до складу lighttpd, - spawn-php.sh.

Скрипт використовує набір конфігураційних змінних на які ви повинні звернути увагу:

Як тільки ви вказали необхідні вам значення, ви можете запустити spawn-php.sh:

Якщо ви бачите "child spawned successfully: PID:" значить php процес запущений успішно. Ви повинні побачити їх в своєму списку процесів:

Число процесів має бути PHP_FCGI_CHILDREN + 1. В даному випадку процес 6925 це master slave'ов працюють паралельно. Число робочих процесів вказується в PHP_FCGI_CHILDREN. Робочий процес автоматично завершує свою роботу після обробки PHP_FCGI_MAX_REQUESTS запитів, тому що в PHP можуть виникнути витоку пам'яті.

Якщо ви запустите скрипт як користувач root, php процеси будуть працювати з призначеним для користувача USERID і GROUPID групи. В іншому випадку php процеси запустяться з правами того користувача які запустив скрипт.

Так як скрипт може бути запущений з невизначеного рівня запуску або навіть безпосередньо з командного рядка, він очищає змінні оточення перш ніж запустити процеси. ALLOWED_ENV містить всі зовнішні змінні оточення які повинні бути доступні php-процесів.

Для Perl ви повинні встановити FCGI модуль з CPAN.