> Причина в бекенде, да. Но переписать весь софт "правильно"
> - не хватит времени и сил. Например, вот та же MediaWiki.
Кстати MediaWiki, использует переменую $_SERVER['HTTP_HOST'] без всякой проверки.
Если вы используете MediaWiki, советую поискать в коде $_SERVER['HTTP_HOST'] и изучить степень угрозы.
> Если все делать на бекенде - тогда вам nginx просто не нужен.
У нас изначально РНР фрейворк проектировался как REST приложения, в нем очень приятно реализовывать логику на уровне HTTP.
По этому мне привычней и удобней это делать имино на бекенде.
Наверно ваше мнения было таким же, если вместо MediaWiki, вы использовали что-то более подходящее на роль REST приложения.
Я ничего не имею против MediaWiki но именно из-за таких фрейморков удобней что-то дописать в конфиге вебсервера, вместо реализации этой логики на уровне HTTP протокола, в самом приложении, что дает возможность понимать вашу логику приложения, всем кто понимает HTTP заголовки.
> Оптимальный вариант - это все-таки делать на стороне nginx то, что
> он умеет делать лучше всего (SSL, gzip, кеширование, отдача статики)
> а на стороне backend`а - только генерирование контента для динамики.
Мы со временем пришли к тому что и контент сжимаем в gzip, сразу на бекенде.
Если есть Nginx кеширования, такая схема работает намного эффективней.
Папка кеша занимает меньше места, считывания происходит быстрей, Nginx не тратит проц время на сжатия.
Главное не забыть включить gunzip, он нужен для клиентов которые не понимают gzip, для них Nginx отдаст несжатый ответ, таких клиентов мало, 10% - 15%.
Таким образом мы один раз сжали ответ на бекенде, потеряли там 2-5ms времени, но Nginx будет сотни раз отдавать этот ответ из своего кеша, таким образом мы сэкономили в сотни раз больше процессорного времени и в несколько раз сэкономили место на диске под файл кеша.
> И он даже быстрее, чем https://github.com/kakserpom/phpdaemon ?
PhpDaemon - это не лучший пример, в плане производительности, он слишком универсален и тяжелый.
На роль, легкого простого демона, он не подходит однозначно, но сам проект вызывает уважения и многие вещи нами были подсмотрены и сделаны по своему.
В это плане, более интересный ReactPHP.
Вот не плохая статья на русском.
http://habrahabr.ru/post/220393/
> Выложить свой phpd в open source не планируете?
Это зависит не только от меня, сейчас в планах этого нет.
Даже моё желания написать статью про ревалидацию кеша через ETag, и отдать ответ c 304 статусе и уложится за 5ms, мои колеги встретили неоднозначно, некоторые даже посчитали что это нарушает их автор право, но принципиально особо никто не против.
Если хотите проверить на что способен, PHP модуль Event, можете создать простой скрипт, который будет что-то отдавать на HTTP запрос.
В самом модуле есть простой встроенный вебсервер, его вполне достаточно, чтобы потестить в ab.
Я был приятно удивлен, но в простом синтетик тесте, который выдаёт строку Ok, этот модуль оказался быстрей встроенного net/http который используется в Golang.
<?php
$base = new EventBase();
$http = new EventHttp($base);
$http->bind('0.0.0.0', 8080);
$http->setDefaultCallback('App\responseHTTP');
$base->loop();
?>
Ваша функция App\responseHTTP, принимает объект request и отдает через него заголовки и тело ответа.
Скрипт работает в одном потоке, Libevent сам держит пул конектов и асинхроно отвечает.
РНР просто синхроно, обрабатывает запросы один за другим, на один простой запрос уходит 2-7 ms.
Очень советую, надеюсь РНР будет развиватся в этом направлении, и когда-то мы получим ApplicationServer из коробки, который будет работать действительно на FastCGI модели.
