Fastcgi в php
До сих пор не утихают споры по этому вопросу. Однозначного мнения нет, всё зависит от задачи, и от того, насколько ваш код оптимизирован к работе в fastCGI режиме. Вот материалы, которые помогут вам разобраться в теме:
 — Статья Дмитрия Котерова про php fast-cgi
 — Вриант от создателя phpDaemona
 — Статья по настройке php5-fpm
 — Статья Ильи Кантора по скрещиванию Symfony и Fast-Cgi

По поводу тестов и сравнения:
 — php-fpm VS apache2+mod_php
 — Apache + mod_php compared to Nginx + php-fpm
 — Comparing Nginx+PHP-FPM to Apache-mod_php
 — Битва PHP: Apache vs PHP-FPM

Некоторые соображения:
Вся технология PHP-FCGI базируется на чем угодно, только не на том, что из себя представляет fast cgi для таких например языков как Perl & C со своими интерфейсами скриптинга.

Если уравнять условия apache и php-fpm, php-fpm единственное в чем выигрывает, то это в памяти, ито за счет двух дополнительных процессах апача. Остальные выигрыши довольно сомнительны.

Если с апача убрать обработку статики и всего лишнего (например с помощью nginx), он довольно шустро обрабатывает скрипты.

С другой стороны, в PHP-FPM довольно красиво реализована схема chroot’а и запуска из под отдельных юзверей, что повышает безопасность. Но он проигрывает в IPC, т.к. пока не умеет изменять количество воркеров пропорционально нагрузке. Если поставить слишком много воркеров, будет overhead по CPU и памяти (за что грешат на апач), если поставить слишком мало – будут отказы в обслуживании. Ну впрочем, кому резонно вручную следить за процессами FPM, те этим занимаются.
Использую php fast cgi на нашем проекте. но правда только конкретно для определенной части приложения.
нам надо было связать высоко нагруженную часть приложения (трэкинг переходов по ссылкам) с IBM MQ Web Sphere и с MySQL

Пришлось допилить руками код на с. но в итоге получили следующее:
Каждый сервер apache поднимает (взависимотси от нагрузки) от 5 до 100 форков приложения и каждый форк держит постоянные соеденения с MQ или с MySQL. Что дало прирость в скорости и решило проблему с кол-вом открытых соеденений. 

Полностью переключиться на fast-cgi не получилось. Некоторые компоненты не захотели работать под fast-cgi частью поэтому пришлось разбивать на части.