1 Отредактировано Koc (2013-10-15 00:41:30)

Тема: Сложности при использовании full page http-cache и пути их решения

Наконец-то дошли руки до сабжа. Столкнулся с такими проблемами:

1. Т.к. в кеш попадает вся страница - мы больше не можем логировать просмотр страницы, если используем какую-то внутреннею статистику просмотров. Приходится слать аяксовые запросы или вставлять картинку 1x1 пиксель.

2. Если выводим даты в формате N секунд/минут назад - это тоже не работает и приходится рулить яваскриптом.

3. Если у нас раньше в onKernelRequest была зашита какая-то логика, например: редирект на мобверсию (в зависимости от user-agent), редирект на другой домен (в зависимости от айпи) - нам теперь нужно это на уровне вебсервера прописывать, что сложнее при интеграции - нужно дергать админов, они могут что-то напутать и тд.

4. С залогиненым пользователем вообще все сложно. В том числе, если нам нужно обновлять у него lastVisitedAt (тоже извращаемся с 1x1 пикселем)

5. Сброс кеша по паттерну. К примеру, у нас есть всеразличные сортировки/фильтры: list/order=field&dir=asc. И вот нам нужно сбросить все-все-все возможные комбинации. И тут вообще черт знает что происходит.

6. Забивание кеша злоумышленниками. Допустим, у нас есть какой-то разумный предел на размер кеша. И вот, злоумышленник начинает открывать страницы со случайной query string. Новые результаты попадают в кеш, вытесняя старые, действительно нужные.

Возможно я какие-то вещи не до конца понимаю или что-то неправильно делаю? При добавлении кеша логика приложения сильно размывается, замыливается. Вероятность возникновения багов возрастает в разы.

С какими проблемами сталкивались вы и как их решали? Какие варианты решения можете предложить для моих?

2

Re: Сложности при использовании full page http-cache и пути их решения

Koc пишет:

Какие варианты решения можете предложить для моих?

Не пользоваться full page http-cache, когда вам нужны все вышеперечисленные фичи? Полный кеш на то и полный, что он соответствует полностью статической html странице. Какое логгирование просмотров, обновление дат и другой информации, бизнес-логику вы на ней хотите получить?

Koc пишет:

Сброс кеша по паттерну.

Если я все правильно понимаю, то сброс full page http-cache по задумке осуществляется по времени. Соответственно никакой специальной бизнес-логики для умного управления кешем не предусмотрено. Если вам надо, можете создать собственное решение.

Koc пишет:

Забивание кеша злоумышленниками.

Мне почему-то представляется, что кеш, автоматически генерирующийся на любую страницу без разбора, тупо по урлу — это исключительно проблема некомпетентности разработчика.

P.S: Я, мягко говоря, не поклонник этой технологии, и считаю, что кешировать вывод в 99% случаев непроизводительно. Технология предназначена для неперсонализированных статичных (или почти статичных, редко изменяемых) часто посещаемых страниц. В остальных случаях она, скажем так, неинтересна.

3

Re: Сложности при использовании full page http-cache и пути их решения

не пользоваться full page http-cache, когда вам нужны все вышеперечисленные фичи?

а как быть если сайт пиздецки тормозит при малейшей нагрузке? Страницы грузятся по 7 секунд. Отдельный серв, но на нем много проектов. Тормозит именно php, не база. В базу там запросы простейшие и их мало. Инициализация, роутинг, twig, гидрация доктрины - в основном это тормозит.

Если я все правильно понимаю, то сброс full page http-cache по задумке осуществляется по времени.

Не всегда это возможно. Добавили коммент - нужно сбросить кеш, что б он сразу появился.

Соответственно никакой специальной бизнес-логики для умного управления кешем не предусмотрено.

Ну вот такое ж есть, http://symfony.com/doc/current/book/htt … tag-header , только я не понимаю, как оно работает? По логике же вся суть http cache в том, что б запрос до php не проходил. А тут варниш будет делать head request что ли?.

Мне почему-то представляется, что кеш, автоматически генерирующийся на любую страницу без разбора, тупо по урлу — это исключительно проблема некомпетентности разработчика.

вот я кеширую страницу просмотра конкретного места (/place/1). Теперь какой-то мудак начал добавлять случайные параметры к ней: (/place/?mt=1234). Я должен все это трекить и отдавать 404-е? Никто так не делает же.

кешировать вывод в 99% случаев непроизводительно

а что кешировать тогда если сайт тормозит?

4

Re: Сложности при использовании full page http-cache и пути их решения

Да, как бы нужно добавить сервер-два чисто под php, но в данный момент такой возможности нет. + добавлять по серверу на каждые 100 уников не вариант же. Цифра 100 естественно взята из головы, я пока не знаю что там как.

5

Re: Сложности при использовании full page http-cache и пути их решения

Koc пишет:

а как быть если сайт пиздецки тормозит при малейшей нагрузке?

Koc пишет:

Не всегда это возможно. Добавили коммент - нужно сбросить кеш, что б он сразу появился.

Я одного не понимаю. Почему вы решили, что именно эта технология подходит вам для решения вашей проблемы? И почему считаете, что ваши желания она должна как-либо учитывать?

Koc пишет:

Я должен все это трекить и отдавать 404-е? Никто так не делает же.

Почему? Вообще-то отдавать 404 тут совершенно необязательно, достаточно просто сверяться с роутом, не учитывать все левые параметры и отдавать ту же страницу.

Koc пишет:

Ну вот такое ж есть

Это логика для клиента. Она позволяет отдать клиенту вместо страницы просто 304 заголовок, если у клиента в браузере уже есть кеш именно этой страницы. К управлению самим кешем на сервере она никакого отношения не имеет.

Koc пишет:

а что кешировать тогда если сайт тормозит?

Вообще-то правильным подходом было бы выяснить, что именно тормозит и почему. И, соответственно, оптимизировать/закешировать только нужные участки/данные. А не использовать полностраничный кеш и материться на возникающие с ним проблемы, связанные с динамическим контентом.

Re: Сложности при использовании full page http-cache и пути их решения

Koc пишет:

а как быть если сайт пиздецки тормозит при малейшей нагрузке? Страницы грузятся по 7 секунд. Отдельный серв, но на нем много проектов. Тормозит именно php, не база. В базу там запросы простейшие и их мало. Инициализация, роутинг, twig, гидрация доктрины - в основном это тормозит.

1. Разобраться с процессором. Достаточно ли его? Тормоза роутинга - это что-то с чем-то.

2. Разобраться с Монологом.

3. Разобраться с формированием страниц - может они не кладутся в кеш Симфони?

4. Включить в настройках APC-кеш.

5. Если помогло мало или уже сделано - лезть в код и кешировать результаты работы внутренней логики.

Koc пишет:

вот я кеширую страницу просмотра конкретного места (/place/1). Теперь какой-то мудак начал добавлять случайные параметры к ней: (/place/?mt=1234). Я должен все это трекить и отдавать 404-е? Никто так не делает же.

Можно настроить .htaccess

Koc пишет:

а что кешировать тогда если сайт тормозит?

У вас он как-то странно тормозит. Похоже, машине не хватает ресурсов. И сильно. И кеш Симфоневский не используется, что приводит к полной перегенерации всего используемого PHP-кода при каждом запросе.

7 Отредактировано Koc (2013-10-15 17:12:03)

Re: Сложности при использовании full page http-cache и пути их решения

хех. Конечно все сконфигурировано для продакшена. Чеклист:

1. прод окружение, дебаг отключен
2. установлен apc, 380 mb shm size, apc stat = on (т.к. иногда на живом нужно что-то поправить)
3. кеш аннотаций доктрины, разбора dql, аннотаций валидации в apc
4. оптимизация автолоадинга в композере
5. apc autoloader

8

Re: Сложности при использовании full page http-cache и пути их решения

Koc пишет:

(т.к. иногда на живом нужно что-то поправить)

А не проще после того, как что-то поправили, просто перезапустить сервис (опач/фпм/что_у_вас_там)?

Ну и, смотрите на расход ресурсов и их распределение между сервисами. Может у вас просто памяти на сервере не хватает для нормальной работы и сервер тупо в своп уходит?

Re: Сложности при использовании full page http-cache и пути их решения

Странно. Если это сделано и это точно продакшн, то что у вас за операционка, проц, память и жёсткий диск?

P.S. Генерацию *новых* страниц за более, чем 5 секунд, я видел только на винде ХП с Денвером на ноуте шестилетней давности, медленным диском и при явной нехватке памяти. Симфони была стандартно настроена под dev-окружение. Генерацию повторно посещённых страниц за время большее, чем 2 секунды, я не видел даже там.

10

Re: Сложности при использовании full page http-cache и пути их решения

Intel® Xeon® E3-1245 Quad-Core, 32 GB DDR3 ECC, 2 x 3 TB HDD SATA3 (software RAID1). FreeBSD. Ну там около дюжины джейлов стоит на разные проекты. Озухи хватает, в основном проц загружен и диски.

11

Re: Сложности при использовании full page http-cache и пути их решения

Ну, что тут можно сказать... Мистика, как она есть. default/smile При таких параметрах машины, пусть даже и поделенных между десятком проектов, получить дикие тормоза и только на Симфони (остальные проекты ведь нормально работают, я правильно понимаю)? Нужно страшное колдунство...

P.S. Вы пробовали запускать проект локально, какие результаты? Если проект так себя ведет на боевом сервере, то на вашей рабочей машине он вообще полчаса отрабатывать должен. Если на рабочей машине он ведет себя бодрячком, то проблема может быть либо в сервере, либо в нагрузке (количественной или качественной, например конкурентные запросы к каким-либо ресурсам).
Далее. Подсчитать текущую нагрузку не так сложно, хотя бы по логам оцените частоту запросов. А то может у вас там случайно прилетает штука rps и раскатывает сервер в асфальт.
В любом случае, активное использование процессора — не совсем штатная ситуация для случая, когда нет никакой серьезной вычислительной логики, быстрее должна заканчиваться память. Дисковая нагрузка также видится странной — APC весь код держит в памяти, вся конфигурация закеширована в пхп, к диску для обработки запроса обращаться вообще не нужно. Наличие дисковой активности говорит о том, что что-то явно работает не так.

12

Re: Сложности при использовании full page http-cache и пути их решения

остальные проекты ведь нормально работают, я правильно понимаю

когда как. Иногда из-за симфони тупят, иногда сами нагружают запросами в сфинкс. Диск грузят следующие вещи: полностраничный кеш на другом проекте (там около 40 гб этого кеша), сфинкс, отдача статических картинок. Штукой rps и не пахнет, к сожалению.

на локальной машине под core i5 в дев-окружении под линуксом до секунды генерация страницы, в среднем 800 мс.

13

Re: Сложности при использовании full page http-cache и пути их решения

Koc пишет:

на локальной машине под core i5 в дев-окружении под линуксом до секунды генерация страницы, в среднем 800 мс

Ну, вполне штатная цифра. Т.е. в самом проекте ничего аномального.

14

Re: Сложности при использовании full page http-cache и пути их решения

Есть ли какой-то эталонный бенчмарк на sf2, по которому можно будет понять, все ли ок настроено на сервере? Грубо говоря, клонируем какой-то репо, запускаем ab с определенными параметрами и смотрим - если тянет N rps - все ок, если нет - то что-то не так с конфигурацией сервера.

Re: Сложности при использовании full page http-cache и пути их решения

Итого, проект в прод-окружении на заведомо более мощном железе работает в 7-10 раз медленнее, чем в дев-окружении с логами, без APC-кеширования и прочих плюшек. Чудес не бывает. Дело не в Симфони и не в этом проекте. Оптимизировать нужно не его.

16 Отредактировано Koc (2013-10-16 20:51:20)

Re: Сложности при использовании full page http-cache и пути их решения

ну тут нужно быть честным: на дев-окружении нагрузки никакой, один разработчик. А на лайве все-таки люди шарятся. И на деве все-таки есть apc (только как опкод-кешер). Правда есть и xdebug, который явно не прибавляет скорости.

Re: Сложности при использовании full page http-cache и пути их решения

В порядке треша - посмотрите на время и дату создания базовых файлов в кеше. Может почему-то кеш пересоздаётся при каждом запросе и оттуда нагрузка на диск?

18

Re: Сложности при использовании full page http-cache и пути их решения

Хорошее замечание. Но, к сожалению, нет. Вчера был вылит последний апдейт - вчера все файлы и были созданы/изменены. Ну логи пишутся о 404/500, но там их немного, не критично.