1) А для обработки параллельно поступивших 1000 запросов, обязательно создавать 1000 процессов PHP-интерпретатора?
2) Нельзя постоянно держать в памяти процесс-интерпретатор и последовательно через FastCGI с фронтэнда слать ему запросы? Наверное так не делают потому, что PHP-интерпретатор может пойти в базу или по HTTP в какое-нибудь API google для верификации капчи и тогда все остальные входящие пользовательские запросы встанут в очереди.
3) А можно создать процесс-пул php-интерпретаторов, который бы через FastCGI принимал от фронтэнд-сервера/балансера запросы и внутри себя переиспользовал уже готовые php-интерпретаторы, где уже всё проинициализировано? Короче, обязательно новый UNIX-процесс рожать на каждый запрос, если мы не хотим блокировать все входящие запросы своим походом в базу?
4) Я клоню к тому, что идеальному серверу не нужно процессов больше количества ядер, а все сетевые входящие и исходящие операции могут быть обработаны асинхронно на epoll или kqueue. То есть процесс, обрабатывающий пользовательский запрос, может в какой-то момент времени находиться в состоянии ожидания по 100 соединениям в базу и при этом принимать новые запросы. Ему нужно только иметь 100 объектов, хранящих состояние каждого запроса.
