Comments 38
UFO just landed and posted this here
Кэш ускорил проекты, что и являлось главной задачей. Нашей целью были минимальные сроки и минимальные изменения кода приложений. Собственно этого мы и достигли, а цена оказалась минимальной. Кроме того в статье написали не только про кэш.
но по факту название не соответствует действительности. Вы написали в духе «желтых» газет. Вместо того, что бы написать: «Как мы ускорили проекты компании», вы пишите об ускорении PHP, к которому, по факту статья никакого отношения не имеет.
Я когда-то делал проще: при запросе я на РНР писал в мемкеш и отдавал контент, а при повторном запросе сам nginx вычитывал данные из мемкэша и отдавал их. Дополнительно использовал SSI.
Попробуйте сделать кеши на стороне nginx для динамических страниц. Вот это бы было интересно.
Так? В этом так то тоже нет никакого rocket-science. Совсем.
Так? В этом так то тоже нет никакого rocket-science. Совсем.
Как ускорить PHP преложение — не запускать его ;)
if-ы в nginx прекрасно заменяются на map (более православный вариант). Приведенный скрипт на LUA вполне заменяем на что-то в духе:
в основном конфиге nginx. Можно делать и более сложные варианты. К примеру у меня такой был: «все запросы на https редиректить на http кроме некоторых адресов»:
Теперь достаточно в одном месте дописывать эти адреса и не копаться в if-ах разных location-ов.
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-ов.
Как мы ускорили 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 :)
А чем бы он помог в этом случае?
UFO just landed and posted this here
Он не рассчитан на кеширование динамики, только статика. Можно по-моему через Page Rules принудительно включить, но это уже будет извращение.
Вы просто не умеете его готовить :)
Хотя там вроде порядка 40 серверов.
Кеш на каждом отдельный.
Хотя там вроде порядка 40 серверов.
Кеш на каждом отдельный.
Ничего не извращение.
CloudFlare + nginx = кешируем всё на бесплатном плане
Смысл в том, что можно все кешировать. Правда для кеширование динамики надо будет добавлять что-нибудь к адресу (чтобы кеш был каждый раз новый для группы юзеров, или баловаться с чисткой кеша через API раз в 15 минут (если там новостной сайт со средний временем обновления 15 минут).
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 подошёл.
Может нужно было просто прописать:это привело бы к тому, что если пришел первым HEAD запрос, то он бы попал в кэш и для GET запросов отдавался кэш от HEAD.
fastcgi_cache_key $uri;
>это привело бы к тому, что если пришел первым HEAD запрос, то он бы попал в кэш и для GET запросов отдавался кэш от HEAD.
Можно было добавить в ключ метод :)
Не знаю, как для фастцги, но прокси позволяет кешировать GET и HEAD (любые другие методы) вместе, отправляя 1 GET запрос на бекэнд.
Вы сами себе создали проблему, а потом ее решили костылями :)
Можно было добавить в ключ метод :)
Не знаю, как для фастцги, но прокси позволяет кешировать GET и HEAD (любые другие методы) вместе, отправляя 1 GET запрос на бекэнд.
да, именно так — у каждого свой fastcgi cache
Вы сами себе создали проблему, а потом ее решили костылями :)
Можно было добавить в ключ метод :)
Мы так и делаем.
отличная статья!
Интересно, что должен делать upstream, чтобы upstream response time был 3-5 секунд?
Я надеюсь что заголовок для skip cache в статье был изменен? А то вы сильно рискуете если кто-то решит получить DoS на свои бекенды.
Эх, костыль костылём погоняет…
Так у вас используется lsyncd для дистрибуции кеша или кеш генерируется обходом бота?
Сколько у вас nginx серверов?
Я понял из предыдущего ответа, что 1.
Сколько у вас nginx серверов?
Я понял из предыдущего ответа, что 1.
Sign up to leave a comment.
Как мы ускорили PHP-проекты в 40 раз с помощью кэширования