Так же было заявлено, что шаблонизатор незначительно влияет на производительнось, потом правда оказалось, что это должен быть особенный «тру» шаблонизатор на С.
Задача: вывод таблицы с 500 рядами, шаблон с одним инклюдом.
PHP-шаблон
$ ab -t10 -c30 http://127.0.0.1/test/php/index.php
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Finished 14019 requests
Server Software: nginx/1.0.15
Server Hostname: 127.0.0.1
Server Port: 80
Document Path: /test/php/index.php
Document Length: 41464 bytes
Concurrency Level: 30
Time taken for tests: 10.001 seconds
Complete requests: 14019
Failed requests: 0
Total transferred: 582994134 bytes
HTML transferred: 581283816 bytes
Requests per second: 1401.76 [#/sec] (mean)
Time per request: 21.402 [ms] (mean)
Time per request: 0.713 [ms] (mean, across all concurrent requests)
Transfer rate: 56927.48 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 2
Processing: 5 21 1.2 21 48
Waiting: 5 21 1.1 21 43
Total: 5 21 1.2 21 48
Percentage of the requests served within a certain time (ms)
50% 21
66% 21
75% 22
80% 22
90% 22
95% 22
98% 24
99% 24
100% 48 (longest request)
$ ab -n10000 -c30 http://127.0.0.1/test/php/index.php
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.0.15
Server Hostname: 127.0.0.1
Server Port: 80
Document Path: /test/php/index.php
Document Length: 41464 bytes
Concurrency Level: 30
Time taken for tests: 7.147 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 415860000 bytes
HTML transferred: 414640000 bytes
Requests per second: 1399.17 [#/sec] (mean)
Time per request: 21.441 [ms] (mean)
Time per request: 0.715 [ms] (mean, across all concurrent requests)
Transfer rate: 56822.26 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 2
Processing: 10 21 1.1 21 47
Waiting: 10 21 1.0 21 46
Total: 10 21 1.0 21 47
Percentage of the requests served within a certain time (ms)
50% 21
66% 21
75% 22
80% 22
90% 22
95% 22
98% 23
99% 24
100% 47 (longest request)
Haanga
$ ab -t10 -c30 http://127.0.0.1/test/haanga/index.php
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Finished 13064 requests
Server Software: nginx/1.0.15
Server Hostname: 127.0.0.1
Server Port: 80
Document Path: /test/haanga/index.php
Document Length: 42977 bytes
Concurrency Level: 30
Time taken for tests: 10.000 seconds
Complete requests: 13064
Failed requests: 0
Total transferred: 563088435 bytes
HTML transferred: 561494505 bytes
Requests per second: 1306.39 [#/sec] (mean)
Time per request: 22.964 [ms] (mean)
Time per request: 0.765 [ms] (mean, across all concurrent requests)
Transfer rate: 54988.81 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 2
Processing: 7 23 1.3 23 52
Waiting: 6 22 1.3 22 49
Total: 7 23 1.3 23 52
Percentage of the requests served within a certain time (ms)
50% 23
66% 23
75% 23
80% 24
90% 24
95% 24
98% 25
99% 26
100% 52 (longest request)
$ ab -n10000 -c30 http://127.0.0.1/test/haanga/index.php
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.0.15
Server Hostname: 127.0.0.1
Server Port: 80
Document Path: /test/haanga/index.php
Document Length: 42977 bytes
Concurrency Level: 30
Time taken for tests: 7.829 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 430990000 bytes
HTML transferred: 429770000 bytes
Requests per second: 1277.26 [#/sec] (mean)
Time per request: 23.488 [ms] (mean)
Time per request: 0.783 [ms] (mean, across all concurrent requests)
Transfer rate: 53758.44 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 6 23 1.3 23 47
Waiting: 6 23 1.3 23 46
Total: 7 23 1.3 23 47
Percentage of the requests served within a certain time (ms)
50% 23
66% 24
75% 24
80% 24
90% 24
95% 25
98% 26
99% 27
100% 47 (longest request)
Разница просто убивающая, особенно на втором тесте.
Нам действительно не о чем говорить.
Желаю успехов в натагивании PHP на HTML.
Нужно исходить из особенностей конкретных проектов.
Конечно нужно.
Разница в том, что практически в любом проекте шаблонизатор будет самым последним «узким» местом или не будет вовсе.
Совершенно очевидно, что парсинг шаблона средствами PHP дело накладное. Начиная от памяти на инициализацию парсера, заканчивая временем исполнения.
Конечно очевидно. Также очевидно, что парсинг шаблона — операция одноразовая, после которой он автоматически превращается в plain-php код с разной степенью оверхэда.
Если у вас шаблоны парсятся постоянно, у меня для вас плохие вести.
Будь у вас оыт профилирования PHP кода шаблонизатора в каком нибудь cachegrind, вы бы так не утверждали.
На это я вам сразу возражу, натравите на свой скрипт 2000 rps рандомных запросов.
Все это делалось и не раз.
Именно поэтому я и утверждаю, что использование шаблонизаторов оправдано в подавляющем большинстве случаев.
Альтернатива должна иметь место быть. Прислушиваться к мнениям также стоит, даже если они кажутся глупыми. В них может скрываться потребность разработчика с которой вы еще сталкивались.
Совершенно верно.
Я — не упоротый олень и далек от мысли: «шаблонизаторы надо использовать в 100 случаях из 100».
Только альтернатива должна быть аргументированной.
«Использую А вместо В, потому что он потребляет на Х меньше памяти и Y процессора, и для меня это критично» — это аргумент.
«Использую А вместо В, потому что он быстрее в 10 раз (1000 микросекунд)» — извините, но в контексте беседы это совершенно не аргумент. «Потому что я так привык и мне так удобно» — тем более.
Причем тут js и css вообще для этого есть отдельные файлы.
При том, что они бывают и не в отдельных файлах.
Ну ок, убераем js/css. Вы серьезно считаете оборачивание всего html (с пареньем мозга как проэскейпать где надо) в echo годным решением?
Я считаю, что давно пора вынести работу с шаблонами из php и серверсайда в принципе.
Для этого есть куча удобных JS библиотек от jq,backbone, angular и тп до ExtJs и подобным.
Речь о PHP, а не JS.
Я возьмусь утверждать, что использование шаблонизатора значительно уменьшает производительность приложнения, нежели использование php как нативного шаблонизатора.
Чем-то подкрепите свое утверждение?
Я вот утверждаю обратное: шаблонизатор уменьшает производительность приложнения незначительно.
И готов/могу это доказывать цифрами.
он отличается в своём подходе от Смарти и Твига тем, что позволяет использовать в представлениях любой свой PHP-код
1. Использование кода в представлении — прекрасный способ отстрелить себе или коллеге яйца. Не обязательно так и произойдет, но вероятность резко возрастает.
2. Могу вас огорчить: и Смарти и Твиг позволяют выполнять кастомный код (непосредственно в шаблоне и/или через хэлперы/экстеншены). С остальными шаблонизаторами история такая же.
лично вёл разработку нескольких проектов, в которых не использовались никакие шаблонизаторы, и был очень доволен результатами
Можно не пользоваться фреймворками и прочими ништяками и также быть очень довольным. О чем разговор?
Можно еще колоться кактусом, вставать на грабли, плевать на устоявшиеся (не только в PHP-мире) best practices. И все ради того, чтоб страница была отдана клиенту за 3с, а не за 3.05с или, о боже мой, за 3.1с. И быть довольным.
Я знаю немало таких довольных людей. И глядя на них понимаю почему только ленивый не поносит PHP.
ЗЫ поправьте если не прав — phpbrew нужно запускать команды чтобы переключить версию php?
Есть несколько вариантов:
— ручное переключение (командой)
— назначение нужной версии дефолтной
— rc-файл (при открытии директории автоматически установится указанная в файле версия)
ну и второе — в проектах же скорее всего не только php используется, как минимум еще нужна база, может быть что-то еще для чего нет возможности ставить разные версии одного софта
Если надо, то разные контейнеры.
В статье написано, что контейнеры отличаются только версией PHP.
в результате у вас получится что вы тестируете в одном окружении, а запускаете в другом
Не совсем так.
Все окружение будет идентичным, за исключением что сам транслятор и его либы будут лежать в другой директории, которая автоматически прописываться в $PATH.
И еще раз повторюсь: я не утверждаю что этот способ единственный верный и подойдет в 100% случаев (хотя за несколько лет фейлов не было).
Я всего лишь предложил более «дешевую» альтернативу для локальной разработки, не более.
Если контейнер предполагается для последущей репликации, то тут уж на ваш выбор.
То есть вы серьезно считаете оборачивание всего html/css/js (с пареньем мозга как проэскейпать где надо) в echo годным решением?
И как, удобно редактировать html в такой каше?
И читается наверное легко и непренужденно?
И верстальщик отдаст вам шаблон именно в таком виде?
Ну и рефакторить код с такими шаблонами одно удовольствие, верно?
И если я могу увеличить в несколько десятков раз скорость работы одного из уровней приложения, без особых потерь от этого — почему бы это не сделать?
Уж не знаю где вы насчитали несколько десятков между 0.002 и 0.02.
Какие будут отговорки, если я вам покажу шаблонизатор, который в сравнении с 0.002 голого PHP будет показывать 0.006?
Опять про оптимизацию расскажете?
Как вы можете судить об отзывчивости, если кроме смарти/блейда ничего не пробовали?
Как на отзывчивости скажется «рендеринг» страницы за 0.002 с (чистый PHP) или 0.02 с (не самый быстрый шаблонизатор)?
Вы понимаете, что в процессе построения страницы обработка шаблона — самая быстрая часть, и основное время будет потрачено на другие задачи?
Haanga написана на чистом PHP.
Даже на тормознутом смарти не будет такого проседания.
Задача: вывод таблицы с 500 рядами, шаблон с одним инклюдом.
Разница просто убивающая, особенно на втором тесте.
Нам действительно не о чем говорить.
Желаю успехов в натагивании PHP на HTML.
Это код, с которым человеку работать не предстоит.
Остальное комментировать не имеет смысла без цифр и кода.
PS а ведь кто-то сам просил без демагогии.
volt — без проблем используется вне phalcon.
xslt — для вас откровение, что его можно использовать как шаблонизатор?
Конечно нужно.
Разница в том, что практически в любом проекте шаблонизатор будет самым последним «узким» местом или не будет вовсе.
Конечно очевидно. Также очевидно, что парсинг шаблона — операция одноразовая, после которой он автоматически превращается в plain-php код с разной степенью оверхэда.
Если у вас шаблоны парсятся постоянно, у меня для вас плохие вести.
Все это делалось и не раз.
Именно поэтому я и утверждаю, что использование шаблонизаторов оправдано в подавляющем большинстве случаев.
Совершенно верно.
Я — не упоротый олень и далек от мысли: «шаблонизаторы надо использовать в 100 случаях из 100».
Только альтернатива должна быть аргументированной.
«Использую А вместо В, потому что он потребляет на Х меньше памяти и Y процессора, и для меня это критично» — это аргумент.
«Использую А вместо В, потому что он быстрее в 10 раз (1000 микросекунд)» — извините, но в контексте беседы это совершенно не аргумент. «Потому что я так привык и мне так удобно» — тем более.
Ну ок, убераем js/css. Вы серьезно считаете оборачивание всего html (с пареньем мозга как проэскейпать где надо) в echo годным решением?
«Если кому-то удобно говнокодить, пусть говнокодит дальше» — отличный аргумент.
Речь о PHP, а не JS.
Чем-то подкрепите свое утверждение?
Я вот утверждаю обратное: шаблонизатор уменьшает производительность приложнения незначительно.
И готов/могу это доказывать цифрами.
Какую версию использовать для хоста задается в настройках web-сервера.
2. Могу вас огорчить: и Смарти и Твиг позволяют выполнять кастомный код (непосредственно в шаблоне и/или через хэлперы/экстеншены). С остальными шаблонизаторами история такая же.
Можно не пользоваться фреймворками и прочими ништяками и также быть очень довольным. О чем разговор?
Можно еще колоться кактусом, вставать на грабли, плевать на устоявшиеся (не только в PHP-мире) best practices. И все ради того, чтоб страница была отдана клиенту за 3с, а не за 3.05с или, о боже мой, за 3.1с. И быть довольным.
Я знаю немало таких довольных людей. И глядя на них понимаю почему только ленивый не поносит PHP.
Есть несколько вариантов:
— ручное переключение (командой)
— назначение нужной версии дефолтной
— rc-файл (при открытии директории автоматически установится указанная в файле версия)
В статье написано, что контейнеры отличаются только версией PHP.
Не совсем так.
Все окружение будет идентичным, за исключением что сам транслятор и его либы будут лежать в другой директории, которая автоматически прописываться в $PATH.
И еще раз повторюсь: я не утверждаю что этот способ единственный верный и подойдет в 100% случаев (хотя за несколько лет фейлов не было).
Я всего лишь предложил более «дешевую» альтернативу для локальной разработки, не более.
Если контейнер предполагается для последущей репликации, то тут уж на ваш выбор.
И как, удобно редактировать html в такой каше?
И читается наверное легко и непренужденно?
И верстальщик отдаст вам шаблон именно в таком виде?
Ну и рефакторить код с такими шаблонами одно удовольствие, верно?
Мой комментарий относится к:
То есть, если цель только иметь различные версии, то отдельные контейнеры для этого избыточны.
Это вы об этом говорите, я лишь комментирую ваше заявление:
При этом сами демонстрируете пример с использованием шаблонизатора.
Вам сюда.
Уж не знаю где вы насчитали несколько десятков между 0.002 и 0.02.
Какие будут отговорки, если я вам покажу шаблонизатор, который в сравнении с 0.002 голого PHP будет показывать 0.006?
Опять про оптимизацию расскажете?
Как на отзывчивости скажется «рендеринг» страницы за 0.002 с (чистый PHP) или 0.02 с (не самый быстрый шаблонизатор)?
Вы понимаете, что в процессе построения страницы обработка шаблона — самая быстрая часть, и основное время будет потрачено на другие задачи?