Pull to refresh

Comments 38

UFO landed and left these words here
Кэш ускорил проекты, что и являлось главной задачей. Нашей целью были минимальные сроки и минимальные изменения кода приложений. Собственно этого мы и достигли, а цена оказалась минимальной. Кроме того в статье написали не только про кэш.
но по факту название не соответствует действительности. Вы написали в духе «желтых» газет. Вместо того, что бы написать: «Как мы ускорили проекты компании», вы пишите об ускорении PHP, к которому, по факту статья никакого отношения не имеет.
Мы не писали об ускорении PHP. Мы писали об ускорении работы PHP-проектов.
Написали бы Web-проектов тогда. Статья хорошая, но не о том.

Согласен с первым комментарием, вы ввели заблуждение заголовком.
Я хотел почитать интересную статью о кешировании в PHP (например для нераспределенного проекта).

Ну и в том числе вы породили кучу очередного холивара про PHP.
Я когда-то делал проще: при запросе я на РНР писал в мемкеш и отдавал контент, а при повторном запросе сам nginx вычитывал данные из мемкэша и отдавал их. Дополнительно использовал SSI.
Попробуйте сделать кеши на стороне nginx для динамических страниц. Вот это бы было интересно.

Так? В этом так то тоже нет никакого rocket-science. Совсем.
Как ускорить PHP преложение — не запускать его ;)
Свежая грамотная шутка.
Вцелом так и получилось: когда проект, по большей части, покрыт кэшем — генерация страниц через php становится минимальной. По сути остались только те части приложения, в которых кэш применить просто нельзя.
Прям как-то всё печально получилось конечно с этой шуткой.
if-ы в nginx прекрасно заменяются на map (более православный вариант). Приведенный скрипт на LUA вполне заменяем на что-то в духе:

map "$request_uri" $skip {
default 0;
"test.php" 1;
}

в основном конфиге nginx. Можно делать и более сложные варианты. К примеру у меня такой был: «все запросы на https редиректить на http кроме некоторых адресов»:

map "$server_port:$uri" $https_redirect {
default 0;

"443:/clean/RbkMoneyCallback" 0;
"443:/robots.txt" 0;
"~^443:.+$" 1;
}


Теперь достаточно в одном месте дописывать эти адреса и не копаться в if-ах разных location-ов.
Да, map-ы работают быстрее «if», но это не решило бы наших задач. Логики на LUA возложено достаточно много, например, эксперименты с распределением запросов на разные лендинги по одному URL, принятие решения о кэширование, редиректы по условию и т.д.
Как мы ускорили PHP-проекты в 40 раз

Ожидал увидеть статью о том, как вы переписали 40 проектов с php на…

Я думаю для некоторых сайтов тетка с перфокартами будет быстрее, чем текущая реализация.

Открыли для себя кеширование… Молодцы…
А теперь ускорьте наконец-то работу фронтенда, а то постоянно идут тормоза в интерфейсе.
кэш на каждом из серверов для одного и того же приложения был свой, пусть и одинаковый.

То есть было примерно так:
upstream php-fpm7.0 {
        server 10.0.0.1;
        server 10.0.0.2;
}

?
И для каждого сервера-бекэнда был свой фастцги-кеш?

использовать lsyncd для дистрибьюции кэша между нодами апстрима

Или выше Вы говорили не о фастцги-кеше, а о кеше приложения?..
Может стоило использовать мемкеш/сетевую фс?
Или у Вас несколько nginx + несколько php?

Соответственно были подтюнены опции fastcgi_cache_path и fastcgi_cache_valid.

Может нужно было просто прописать:
fastcgi_cache_key   $uri;


Могли бы переехать на cloudflare :)
Могли бы переехать на cloudflare :)

А чем бы он помог в этом случае?
Он не рассчитан на кеширование динамики, только статика. Можно по-моему через Page Rules принудительно включить, но это уже будет извращение.
Вы просто не умеете его готовить :)

Хотя там вроде порядка 40 серверов.
Кеш на каждом отдельный.
Ничего не извращение.
CloudFlare + nginx = кешируем всё на бесплатном плане
Смысл в том, что можно все кешировать. Правда для кеширование динамики надо будет добавлять что-нибудь к адресу (чтобы кеш был каждый раз новый для группы юзеров, или баловаться с чисткой кеша через API раз в 15 минут (если там новостной сайт со средний временем обновления 15 минут).
То есть было примерно так:
upstream php-fpm7.0 {
server 10.0.0.1;
server 10.0.0.2;
}

Да. На каждом сервере Nginx + PHP-FPM.
И для каждого сервера-бекэнда был свой фастцги-кеш?

да, именно так — у каждого свой fastcgi cache.

Может стоило использовать мемкеш/сетевую фс?

Сетевую файловую систему использовать не хотелось. Хотели использовать простое и проверенное решение, lsync подошёл.

Может нужно было просто прописать:
fastcgi_cache_key $uri;
это привело бы к тому, что если пришел первым HEAD запрос, то он бы попал в кэш и для GET запросов отдавался кэш от HEAD.
>это привело бы к тому, что если пришел первым HEAD запрос, то он бы попал в кэш и для GET запросов отдавался кэш от HEAD.

Можно было добавить в ключ метод :)

Не знаю, как для фастцги, но прокси позволяет кешировать GET и HEAD (любые другие методы) вместе, отправляя 1 GET запрос на бекэнд.

да, именно так — у каждого свой fastcgi cache

Вы сами себе создали проблему, а потом ее решили костылями :)
Интересно, что должен делать upstream, чтобы upstream response time был 3-5 секунд?
Вроде написано было 1-3.

+Это же вордпресс со множеством плагинов :)
Я сужу по приведённому графику с response time
График приведен для одного из приложений (1-3 секунды это среднее по всем проектам), но замечено правильно — wp + плагины.
Я надеюсь что заголовок для skip cache в статье был изменен? А то вы сильно рискуете если кто-то решит получить DoS на свои бекенды.
Так у вас используется lsyncd для дистрибуции кеша или кеш генерируется обходом бота?
Сколько у вас nginx серверов?
Я понял из предыдущего ответа, что 1.
Сколько у вас nginx серверов?
Я понял из предыдущего ответа, что 1.

Как раз таки из их ответа следует, что у них на каждом сервере по nginx.
Only those users with full accounts are able to leave comments. Log in, please.