Если интерпретатор выполняет скрипт за 100ms то не особо важно кто его запускает сверху, который добавляет лишь оверхед тем или иным способом.
Можно считать, что 100ms это нижняя грань с точки зрения nginx/apache/консоли/того кто висит на сокете... Можно снизить только конфигами самого интерпретатора или оптимизацией кода, кешерами, php7. Но явно не за счет того кто и как запустил этот скрипт.
Уж поверьте, я прекрасно знаю как это все работает и много всякого настраивал как руками, так и автоматом. И через сокеты (у меня так сейчас несколько демонов работают с http на разных портах, один на жаве, другой на питоне, и кажется третий на перле) и модулям настраивал, и cgi и через mpm worker в апаче (все три пробовал)... И даже иногда собирал это добро из исходников для фана в генте =) Хорошо представляю, что именно вы сделали в конфигах и что это значит в практическом плане

Не знаю что вы пытаетесь доказать)) Выше так и говорил, nginx легче потому что уже запущен, а apache - все время запускается и плодит процессы + apache это комбайн, который изначально решал не только вопрос с вебом, а все подряд за счет модулей. nginx же ориентировался изначально на веб и минимализм за счет чего детище Сысоева получило популярность.
Вот если б весь сайт на php можно было бы запустить как приложение один раз и слушать события на входе, как это делается в той же ноде, то скорость была бы нереально быстрой. Вместо сотен миллисекунд мы бы получили единицы и десятки, это бы практически полностью ликвидировало проблему с I/O, которую решают все эти опкод-кешеры. Получили бы асинхронность как в js))))
Думаю, вы все равно будете считать что nginx ускоряет сам php, а не его пуск. Ну ладно, дело хозяйское =)