Cache revalidation using If-None-Match

[Gena Makhomed]

On 17.07.2014 16:46, S.A.N wrote:

> Если вы посмотрите на причины, из-за которых начинают программировать
> в конфигах Nginx, то причина одна, бекенд что-то не так делает.

"бекенд что-то не так делает" - это уже следствия.

А причина в том, что большинство приложений на PHP
написаны изначально из расчета, что они будут запускаться
на Apache + mod_php. В результате чего сами разработчики
этих приложений часть логики вынесли в файлы .htaccess

> Так начинается лечения пациента (бекенда) по симптомам, мы находим условия
> (location) при котором появляется симптом, в этом location прописываем
> рецепт (директивы) больному для его выздоровления.
> Симптомы исчезают, мы радуемся что решили проблему, но мы просто сняли
> симптом, причина была в бекенде.

Причина в бекенде, да. Но переписать весь софт "правильно"
- не хватит времени и сил. Например, вот та же MediaWiki.

В результате приходится делать так
http://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_nginx_rewrite--root_access
или так: http://wiki.nginx.org/MediaWiki

Если приложение писали не для Apache,
а изначально планируя его запускать на nginx+php-fpm,
то там будет, грубо говоря всего две точки входа -
одна для динамики и вторая для статики, плюс location для обработки
404 ошибок к статике. И ничего "программировать" в конфиге не надо.

> По этому я сторонник делать все на бекенде.

Если все делать на бекенде - тогда вам nginx просто не нужен.

Оптимальный вариант - это все-таки делать на стороне nginx то, что
он умеет делать лучше всего (SSL, gzip, кеширование, отдача статики)
а на стороне backend`а - только генерирование контента для динамики.

>> У варианта использования phpd разве есть какие-то преимущества
>> по сравнению с вариантом nginx+php-fpm, если связь между nginx
>> и php-fpm делать через unix domain socket ?
>> подробнее - см. http://php-fpm.org/about/
>> тем более, что phpd уже deprecated
>
> Я не знаю, про какой phpd вы говорите, у нас своя разработка, которая совсем
> не deprecated, скорей на оборот, слишком модная )
> Преимущества по сравнению с php-fpm в основном два, это возможность в
> runtime сохранять своё состояния и нужные данные между запросами и
> отсутствия издержек на инициализацию скриптов при каждом запросе, как это
> всегда происходит в fpm, конечно OPcache помогает, но в демоне все равно
> быстрей.
>
> В качестве веб-сервера используется PHP модуль Event (libenet 2.0)
> http://ua2.php.net/manual/ru/book.event.php
>
> Очень довольны его скоростью и стабильностью.
> Проводили нагрузочное тестирования и сравнивали fpm и наш демон, разница
> оказывалась в разы, в пользу демона.

И он даже быстрее, чем https://github.com/kakserpom/phpdaemon ?

Выложить свой phpd в open source не планируете?

-- 
Best regards,
  Gena