Как сделать так чтобы переводчик не трогал теги?

Zimaell, Можно еще побывать заменять тэги предложениями из целевого языка: h1 -> Заголовок 1.. Если сервис умеет пропускать уже переведенные части и неопирается при переводе на предыдущие предложения, то должно сработать.

Symfony serialize при добавлении определенной связи перестает работать, почему?

Все поняно, так как у вас не просто первый класс ссылается на второй и второй на первый, а через третью сущность, то Doctrine неверно их обрабатывает(это видно по json, что приложили). В таком случаи стоит убрать вывод поля user.assignedTickets, как раз через упомянутый вами массив

[AbstractNormalizer::ATTRIBUTES => ['assignedUsers' => ['assignedTickets']]

, тогда структура будет плоская, но без ухода в рекурсию.

Есть где посмотреть примеры как на относительно реальных примерах работают с сериализатором этим?

Только документация, а дальше уже нужно просто продумывать все запросы. Если говорить относительно этйо задачи, я бы на вашем месте сделал просто один метод в классе репозитория билетов и в нем реализовал SQL-запрос в обход Doctrine, так как в итоге необходимо получить json, а использование ORM дает большие накладные расходы и неоптимальные пачки запросов к БД.

Symfony serialize при добавлении определенной связи перестает работать, почему?

Максим Лагойский,

уже итерации 300+ точно было

У вас там лимит стоит на 10 объектов, так что я могу предположить, что либо очень много билетов на одного пользователя приходится, либо он гораздо раньше вошел в рекурсию. Какое общее кол-во билетов на этих 10 пользователей приходится? Смущает также то, что когда он находит рекурсию и не задано функции для ее обработки, то сериалайзер выбрасывает CircularReferenceException. Попробуйте убрать AbstractNormalizer::CIRCULAR_REFERENCE_HANDLER и посмотреть будет ли бошено исключение, или он и дальше будет падать по памяти.

Symfony serialize при добавлении определенной связи перестает работать, почему?

Максим Лагойский, вы уже это сделали:

AbstractNormalizer::CIRCULAR_REFERENCE_HANDLER => function ($object, $format, $context) {
        return $object->getId();
    },

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

Как правильно организовать частичное кэширование динамики в nginx?

Поставте opcache :) Думаю, нагрузка частично снизится. Не буду раньше времени вас радовать, но думаю примерно в два раза станет лучше, со стороны php (предположение строю, опираясь на эту статью https://habrahabr.ru/post/264775). А вот проблема с mysqld должна остаться.

Как правильно организовать частичное кэширование динамики в nginx?

Alex Plotnikov, я бы на вашем месте замерил скорость работы отдельных блоков - статики и динамики на локальной машине, чтобы иметь представление о том, что дольше рендерится. А также я бы рекомендовал бы выяснить запросы от динамических или статических блоков заставляет mysqld нагружать цп. У вас очень много оперативной памяти, но используется ли она? Сколько при пиковой нагрузке используется памяти на сервере? Может быть, если ее в избытке, стоит произвести тонкую настройку кеша mysql...

Как правильно организовать частичное кэширование динамики в nginx?

Alex Plotnikov, 5-10секунд это при пиковой нагрузке? а если в простое? Чтобы проверить установлен OpCache просто выполните команду в консоле сервера php -v, если будет подобная строка:

with Zend OPcache v7.1.14-1+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

то OpCache есть.

Как правильно организовать частичное кэширование динамики в nginx?

Alex Plotnikov, я бы рекомендовал замерить скорость рендеринга динамической части приложения и статики. А какая версии php? OpCache используете?

Как правильно организовать частичное кэширование динамики в nginx?

Борис Сёмов, внешний кэш можно обновлять не только по ttl, но и используя механизмы инвалидации кеша. Нет, конечно, на стороне приложения тоже должна быть система кэша, но это не панацея. Чаще всего используют обе системы - внешнюю (varnish, ssi, etc) и внутреннюю, что позволяет еще сильнее сократить время отклика и снизить нагрузку.

Как правильно организовать частичное кэширование динамики в nginx?

Борис Сёмов, стратегия кэширования выбирается в зависимости от требуемых задач и имеющихся ресурсов, а вырожение "куда более эффективную" всего лишь ворожение, которое к реальной проблеме не имеет никакого отношения и человеку с его проблемой ни как не поможет. Это тоже самое, если один врач советует больному с пороком сердца сделать операцию, а другой врач парирует: будь он младенцем у него бы было хорошее сердце.

Как правильно организовать частичное кэширование динамики в nginx?

Alex Plotnikov, Varnish либо SSI вам помогут. Нужно понимать, что они придадут скорости приложению за счет обхода рендеринга статики. Динамику же настроить можно так, чтобы она вообще не кэшировалась и тогда решается проблема с раздутостью кэша из-за персонализации. Сложность что моего подхода, что Бориса упирается только в одно - перенос логики вашего динамического блока в отдельный php файл. Плюс, либо настройку кэша на стороне бэка, если выбирать мой вариант, либо настройку кэша и написание js кода, который будет тянуть и рендерить кеш на стороне фронтенда, если выберите вариант Бориса.

Как правильно организовать частичное кэширование динамики в nginx?

Борис Сёмов, а кто говорит о пули? Да придется попотеть, но это возможно. И если использовать ESI изменять код придется минимально по сравнению с SSI. Все зависит от контекста, а контекста мы не знаем. Если в каждом блоке встречается ФИО, то конечно кеш будет раздут из-за того, что придется кэширать каждый такой блок. Если же 99% это статика и 1% динамика - то тут да, лучше сразу пулять 1 запрос аяксом. Если же у нас 50% на 50% и динамика разная - где-то персонализированная, а где-то нет - то я бы выбрал Varnish.

Как правильно организовать частичное кэширование динамики в nginx?

Сам имел дело с Varnish+ESI но на сторое кода был не wordpress, а symfony. Проблем не было, кешировал статические блоки с менее критичной информацией, а блоки с более важной не кешил вовсе.

Как правильно организовать частичное кэширование динамики в nginx?

Alex Plotnikov, конечно можно - либо с ssi либо varnish. Varnish более гибко настраивается, и меньше шаманства с кодом, но больше гемороя в настройках, из-за его гибкости. С ssi больше возни с кодом, за-то настроек мало. Вот две ссылки с примером в вакууме:
https://goo.gl/XMzr3T
https://goo.gl/X9jKrE

Как правильно организовать частичное кэширование динамики в nginx?

Alex Plotnikov, да, вы правы это кеш, но кеш всего ресурса по url которые мы указываем, а не отдельных блоков. Пожалуй, мне стояло это упомянуть в своем ответе.