я правильно понимаю что дело в output buffering?
А в каких случаях он может тормозить?
Свой шаблонизатор в php
- Автор темы 25517
- Дата начала
А в каких случаях он может тормозить?
@Фанат Все правильно понял 
@флоппик даже просто пхп код может тормозить - каждые операции имеют разный вес. Аутпут буфферинг реально тяжелая операция по сравнению с многими другими. Просто включив профилировщик можно это увидеть. И от разового ее применения нет никакой проблемы, но если ее постоянно дрочить могут быть нюансы (а именно это может начать делать твиг). И в некоторых граничных случаях только рендер большого шаблона с большим количеством инклудов (например, когда диз разбит на небольшие компоненты, как сейчас все любят, и компонентов дофига, да еще с несколькими уровнями вложенности, да еще и в циклах) может занимать значительное время во много раз больше запросов к базе и т.д. (на моей практике рекорд 1.5 сек на одном проекте, при условии что весь остальной код с запросами к базе не более 0.05 сек)
Если бы твиг компилировал 1 шаблон и все дерево инклудов в 1 файл, это бы помогло для таких граничных случаев, но это не так.
Но повторю в третий раз - проблема довольно редкая чтобы делать свой велосипед
@флоппик даже просто пхп код может тормозить - каждые операции имеют разный вес. Аутпут буфферинг реально тяжелая операция по сравнению с многими другими. Просто включив профилировщик можно это увидеть. И от разового ее применения нет никакой проблемы, но если ее постоянно дрочить могут быть нюансы (а именно это может начать делать твиг). И в некоторых граничных случаях только рендер большого шаблона с большим количеством инклудов (например, когда диз разбит на небольшие компоненты, как сейчас все любят, и компонентов дофига, да еще с несколькими уровнями вложенности, да еще и в циклах) может занимать значительное время во много раз больше запросов к базе и т.д. (на моей практике рекорд 1.5 сек на одном проекте, при условии что весь остальной код с запросами к базе не более 0.05 сек)
Если бы твиг компилировал 1 шаблон и все дерево инклудов в 1 файл, это бы помогло для таких граничных случаев, но это не так.
Но повторю в третий раз - проблема довольно редкая чтобы делать свой велосипед
На современных версиях PHP это все будут копейки.
Конечно можно взять php 5, да еще и opcache выключить. Или написать такие плагины, которые будут тормозить адово. Или сделать синтетические тесты на 100500 итераций и начинать тестировать нереалистичные кейсы.
И даже в этих случаях есть ext/twig, оптимизирующий ту самую "медленную" функцию
Конечно можно взять php 5, да еще и opcache выключить. Или написать такие плагины, которые будут тормозить адово. Или сделать синтетические тесты на 100500 итераций и начинать тестировать нереалистичные кейсы.
И даже в этих случаях есть ext/twig, оптимизирующий ту самую "медленную" функцию
Ну блин оставлять генерацию больше секунды - это надо быть полным извращенцем, в проблемных местах переписали шаблоны и некоторые компоненты заменили на хелперы вместо инклудов (те что встречались чаще всего) и это помогло.
Нужны тесты - пиши микробенчмарки сколько занимает старт стоп аутпут буфферинга в процентном отношении к другим операциям.
опкод кеш вообще не влияет на эту проблему, как и 7-й пхп, т.к. проблема выполнения, а не компиляции. На 7-ке конечно все быстрее, но вот процентное отношение аутпут буфферинга к времени даже больше чем на 5-ке.
Твиг хорош, но надо знать какие у него могут быть проблемы.
То, о чем ты говоришь, это копейки на фоне остального в реальном проекте. Под бенчмарки можно подогнать конечно.
Понятно, что бывают edge cases, но для 99% проектов этот вклад в общее время ответа мизерен.
Опкеш как раз имеет значение, поскольку компиляция в php пофайловая. Более того, имеют значение настройки опкеша - важно, чтобы из кэша скомпилированные темплейты не вытеснялись.
Определенные проблемы, конечно, могут быть в ситуациях полного хайлоада, когда все закешировано и время рендеринга темплейта становится заметным. Но тут, повторюсь, ext/twig сведет итоговую производительность к близкой к тому же Smarty, сохраняя все преимущества Twig-а.
Понятно, что бывают edge cases, но для 99% проектов этот вклад в общее время ответа мизерен.
Опкеш как раз имеет значение, поскольку компиляция в php пофайловая. Более того, имеют значение настройки опкеша - важно, чтобы из кэша скомпилированные темплейты не вытеснялись.
Определенные проблемы, конечно, могут быть в ситуациях полного хайлоада, когда все закешировано и время рендеринга темплейта становится заметным. Но тут, повторюсь, ext/twig сведет итоговую производительность к близкой к тому же Smarty, сохраняя все преимущества Twig-а.
Где я писал что опкод кеш вообще не влияет???? Я писал что он вообще не влияет на данную конкретную проблему. Да, это эджкейс, но он вылазит как раз на реальных больших проектах.
А то читая по диагонали или вообще не читая сразу накинулись "вы всё врёти!!! твиг не может тормозить!!!" А он все-таки может и иногда сильно, но в очень определенных ситуациях, и учитывая как дизайнеры верстальщики сейчас начинают дробить на кучу мелких компонентов используя инклуд шаблонов (привычка после вью и реакта) шанс возникновения такой ситуации не нулевой.
И не надо рассказывать насчет опкод кеша, пожалуйста...
Блин, сударь, Вы писатель или читатель??? Я с самого начала именно это и написал, что под нагрузкой и что только в определенных юзкейсах!!
А то читая по диагонали или вообще не читая сразу накинулись "вы всё врёти!!! твиг не может тормозить!!!" А он все-таки может и иногда сильно, но в очень определенных ситуациях, и учитывая как дизайнеры верстальщики сейчас начинают дробить на кучу мелких компонентов используя инклуд шаблонов (привычка после вью и реакта) шанс возникновения такой ситуации не нулевой.
И не надо рассказывать насчет опкод кеша, пожалуйста...
Это надо делать через use или macro. Инклюды это как раз привычки от всяких smarty.
только синтетический тест. Сейчас уже не на том проекте, но там шаблоны были здоровые с кучей инклудов (многократная вложенность и циклы), в результате количество инклудов точно было более 50К на некоторых страницах - там и тупило (точные цифры не помню, может и больше, может и на порядок, единственное точно помню что от цифр офигел) . Может тупило еще что-то, но профайлер показывал что именно старт-стоп буферизации отъедал большую часть. Переписывание проблемных шаблонов помогло - замена инклудов на кастомные теги, но думаю и заменой на макросы тоже решилось бы.
Кстати, не удивлюсь если в 7.4 через FFI он будет прокидываться всегда, без телодвижений со стороны админов.
@Yoskaldyr все эти вопросы про реальный пример формулируются так: сколько у проекта одновременных уникальных пользователей в пике?
для Mamba fisher написал шаблонизатор на С, потому что на тысяче серверов по $10 тысяч каждый это сэкономило годовую зарплату команды разработчиков,
когда у меня было 100 тысяч одновременных сессий по нефункциональным требованиям, SLA 5 девяток, датацентры по всем континнтам, и сервера по цене премиальных автомобилей, я потратил год на оптимизацию двух запросов,
а если у тебя 100 тысяч уников в сутки на форуме, который бегает на одном 8-ядерном сервере, как macbook pro - это ты $%^ страдаешь, просто добавь вторую виртуалку, включи кеш в редисе, и сделай что-то полезное
для Mamba fisher написал шаблонизатор на С, потому что на тысяче серверов по $10 тысяч каждый это сэкономило годовую зарплату команды разработчиков,
когда у меня было 100 тысяч одновременных сессий по нефункциональным требованиям, SLA 5 девяток, датацентры по всем континнтам, и сервера по цене премиальных автомобилей, я потратил год на оптимизацию двух запросов,
а если у тебя 100 тысяч уников в сутки на форуме, который бегает на одном 8-ядерном сервере, как macbook pro - это ты $%^ страдаешь, просто добавь вторую виртуалку, включи кеш в редисе, и сделай что-то полезное
@grigori Здесь на форуме стандартная практика не читать а сразу отвечать.
Я написал насчет проблемы твига в редких случаях. И как я описал все выше, проблема никак не связана ни с масштабированием ни с нагрузкой на сервер. Основная проблема для клиента была - латенси больше секунды (и не всегда это можно решить кешем), которое было никак не уменьшить ничем кроме как переписыванием шаблонов (что и было сделано в итоге). Все упиралось тупо в вычисления 1 ядра на 1 cpu. Более мощный сервер не всегда означает более быстрое ядро (очень часто даже медленнее), также поднятие 100500 докеров тоже это не решило бы.
И еще раз повторюсь для пишущих, но не читающих - это эджкейс, да реально редкий, но на который легко можно наступить когда верстальщики верстают полностью отдельно и используют модные и молодежные подходы к делению на шаблоны (по факту верстальщику пофигу инклуд или макро, главное чтобы компонент отдельно и независим от другого компонента).
Я написал насчет проблемы твига в редких случаях. И как я описал все выше, проблема никак не связана ни с масштабированием ни с нагрузкой на сервер. Основная проблема для клиента была - латенси больше секунды (и не всегда это можно решить кешем), которое было никак не уменьшить ничем кроме как переписыванием шаблонов (что и было сделано в итоге). Все упиралось тупо в вычисления 1 ядра на 1 cpu. Более мощный сервер не всегда означает более быстрое ядро (очень часто даже медленнее), также поднятие 100500 докеров тоже это не решило бы.
И еще раз повторюсь для пишущих, но не читающих - это эджкейс, да реально редкий, но на который легко можно наступить когда верстальщики верстают полностью отдельно и используют модные и молодежные подходы к делению на шаблоны (по факту верстальщику пофигу инклуд или макро, главное чтобы компонент отдельно и независим от другого компонента).
Про latency на 50 тысячах инклудов ты не писал. Я как-то чинил nginx, который рекурсивно инклюдил конфиги, и откушал 1 гб оперативки. Это вообще не имеет значения, как segfault на рекурсии. Просто ты написал как о проблеме, которую надо учитывать, и все возбудились. Неограниченные операции недопустимы - инклюды, рекурсию, выделения в регулярках, какие угодно.
Про CPU - нет, более мощные процы быстрее. У меня был аналогичный прикольный кейс - кастомер жаловался на нерегулярные зависания сервиса на 10-15 минут, прислал видео, а воспроизвести не пролучалось. Взяли его данные, запустили запрос на ноуте, все нормально. Я люблю такое, взял задачу себе.
Отпрофайлил, дошел до xslt-трансформаций - тот же шаблонизатор. За пару минут отрабатывает даже ноут, а на серверах ксеоны, откуда 15 минут?
Сел в машину, приехал к админам, дал скрипт на 3 строки, говорю, запускай на продах. На всех серверах отработало за секунды, а на двух - пол-минуты. Все офигели.
Копать дальше никому не надо, конечно, их просто выключили.
Про CPU - нет, более мощные процы быстрее. У меня был аналогичный прикольный кейс - кастомер жаловался на нерегулярные зависания сервиса на 10-15 минут, прислал видео, а воспроизвести не пролучалось. Взяли его данные, запустили запрос на ноуте, все нормально. Я люблю такое, взял задачу себе.
Отпрофайлил, дошел до xslt-трансформаций - тот же шаблонизатор. За пару минут отрабатывает даже ноут, а на серверах ксеоны, откуда 15 минут?
Сел в машину, приехал к админам, дал скрипт на 3 строки, говорю, запускай на продах. На всех серверах отработало за секунды, а на двух - пол-минуты. Все офигели.
Копать дальше никому не надо, конечно, их просто выключили.
Ну, разные случаи бывают. Вспомнит старый начальник о бывшем работнике, например, и придется китайцам подхватить упавшее знамя. Их много, велосипед им нужен.
да, написал не латенси, а то что время рендера больше секунды, но латенси соответственно будет еще больше. Если страница на сервере генерится больше 1 секунды, то пофигу из-за чего это из-за творческих 100500 инклудов шаблонов в рендере или из-за 100500 запросов к базе или еще чего - больше 1 сек это все равно больше 1 секунды