Comments 11
Статья, как вступление к анонсу своего фреймворка :)
Вопрос производительности языка программирования или фреймворка это даже не пятый и не десятый по важности для подавляющего большинства случаев веб разработки.
Сегмент клепания одинаковых сайтов-визиток, да интернет магазинов пластиковых окон/гидромассажных ванн, умещающихся на vps за 50 рублей/год учитывать не будем.
Гораздо важнее тут будут скорость разработки и лёгкость дальнейшей поддержки и написания кода. Если вы не пишете числодробилку, то в конце-концов у вас всё почти наверняка упрётся не во фреймворк, а в базу данных(читай жёсткий диск) и пропускную способность канала.
Пока вы на своём мегабыстром фреймворке будете полгода-год клепать очередной фейсбук, инстаграм или что-то там ещё, другая команда возьмётся делать аналогичный сервис на каком-нибудь в 10 раз более медленном rails, но выпустит проект в разы быстрее, с более качественным кодом и заберёт себе всех ваших потенциальных клиентов. Когда у них будут уже сколько-то десятков или даже сотня тысяч пользователей в сутки на одном сервере, и одного кеширования станет недостаточно, то они тупо докупят ещё сервера.
Лишний сервер стоит копейки по сравнению с зарплатами разработчиков(грубо говоря месяц работы разработчика стоит как аренда 5-20 серверов на том же хетзнере или 2-3 хороших серверов на высококачественном хостинге).
А ещё может быть(и что даже скорее всего и случится) такой посещаемости никогда и не будет, все усилия провалятся, сервис «не взлетит». Команда, делающая быстро на «тормозном фреймворке», начнёт и может быть даже успеет выпустить новую версию очередного проекта, а вы к тому времени только закончите свою первую версию того-что-вы-там-делали, и ещё позже вам лишь предстоит понять, что проект «не взлетел».
Мораль на самом деле такая: фейсбуком вы всё равно никогда не станете, а если и станете, то в большинстве случаев становиться им будете очень постепенно. Решайте проблемы производительности по мере их наступления. Выигрывая в производительности кода, вы обязательно будет проигрывать в чём-то другом. Самый важный и дорогой ресурс в нашей жизни, это время. Оно стоит гораздо дороже железа.
Сегмент клепания одинаковых сайтов-визиток, да интернет магазинов пластиковых окон/гидромассажных ванн, умещающихся на vps за 50 рублей/год учитывать не будем.
Гораздо важнее тут будут скорость разработки и лёгкость дальнейшей поддержки и написания кода. Если вы не пишете числодробилку, то в конце-концов у вас всё почти наверняка упрётся не во фреймворк, а в базу данных(читай жёсткий диск) и пропускную способность канала.
Пока вы на своём мегабыстром фреймворке будете полгода-год клепать очередной фейсбук, инстаграм или что-то там ещё, другая команда возьмётся делать аналогичный сервис на каком-нибудь в 10 раз более медленном rails, но выпустит проект в разы быстрее, с более качественным кодом и заберёт себе всех ваших потенциальных клиентов. Когда у них будут уже сколько-то десятков или даже сотня тысяч пользователей в сутки на одном сервере, и одного кеширования станет недостаточно, то они тупо докупят ещё сервера.
Лишний сервер стоит копейки по сравнению с зарплатами разработчиков(грубо говоря месяц работы разработчика стоит как аренда 5-20 серверов на том же хетзнере или 2-3 хороших серверов на высококачественном хостинге).
А ещё может быть(и что даже скорее всего и случится) такой посещаемости никогда и не будет, все усилия провалятся, сервис «не взлетит». Команда, делающая быстро на «тормозном фреймворке», начнёт и может быть даже успеет выпустить новую версию очередного проекта, а вы к тому времени только закончите свою первую версию того-что-вы-там-делали, и ещё позже вам лишь предстоит понять, что проект «не взлетел».
Мораль на самом деле такая: фейсбуком вы всё равно никогда не станете, а если и станете, то в большинстве случаев становиться им будете очень постепенно. Решайте проблемы производительности по мере их наступления. Выигрывая в производительности кода, вы обязательно будет проигрывать в чём-то другом. Самый важный и дорогой ресурс в нашей жизни, это время. Оно стоит гораздо дороже железа.
По специфике работы мне приходится сталкиваться с проблемами производительности. Бывает так, что несколько десятков строк кода может помочь сэкономить на подключении пары серверов в систему (затраты день разработки, сервера же стоят годами и требуют оплаты). Хотя далеко не всегда все так просто.
В целом с вами полностью согласен, об этом и пост.
В целом с вами полностью согласен, об этом и пост.
То ли дело 1 сайт на сервере держать, а другое дело 10! Профит очевиден же.
Да и посыл статьи как я ее не понял не в том производительность — это самое главаное, а в том какие трудности есть в понимании реальной производительности фреймворков.
Да и посыл статьи как я ее не понял не в том производительность — это самое главаное, а в том какие трудности есть в понимании реальной производительности фреймворков.
Вообще не понимаю синтетические тесты производительности фреймворков/языков программирования, когда в реальности в 99,9% все тормоза банально упираются банально в базу (и кривые руки которые пишут кривые запросы).
На самом деле скорость выполнения скриптов вообще 20ое дело. И если она так важна, то следовательно проект высоконагруженный и суперпосещаемый, а следовательно проще добавить дополнительный сервер, и за счет грамотной монетизации (клиентура то есть, иначе откуда взяться нагрузкам), проект быстро отобьет затраченные на сервер деньги.
На самом деле в случае гонки за скоростью обычно стоит выбирать — либо разрабатываем супергибкий движок, и он будет средним по скорости, либо же забиваем на гибкость, и пишем код так, чтобы все работло супер быстро. Вот кстати пример из реальной жизни — например используем мы супер крутяццкий ORM, извлекаем из БД 500 объектов, и в лучших традициях жанра ORM оборачивает каждый извлеченный элемент в объект. При большом количестве извлеченных объектов (200-300) задержка выполнения скрипта может варьироваться от 50 до 150 ms. И тут уже надо выбирать — либо гибкий ORM, либо выигрываем 50 ms в каких-то кейсах, но забивем на гибкость.
На самом деле скорость выполнения скриптов вообще 20ое дело. И если она так важна, то следовательно проект высоконагруженный и суперпосещаемый, а следовательно проще добавить дополнительный сервер, и за счет грамотной монетизации (клиентура то есть, иначе откуда взяться нагрузкам), проект быстро отобьет затраченные на сервер деньги.
На самом деле в случае гонки за скоростью обычно стоит выбирать — либо разрабатываем супергибкий движок, и он будет средним по скорости, либо же забиваем на гибкость, и пишем код так, чтобы все работло супер быстро. Вот кстати пример из реальной жизни — например используем мы супер крутяццкий ORM, извлекаем из БД 500 объектов, и в лучших традициях жанра ORM оборачивает каждый извлеченный элемент в объект. При большом количестве извлеченных объектов (200-300) задержка выполнения скрипта может варьироваться от 50 до 150 ms. И тут уже надо выбирать — либо гибкий ORM, либо выигрываем 50 ms в каких-то кейсах, но забивем на гибкость.
Как я полагаю гонка за «победы» в тестах среди разработчиков framework, заключается в предложении схожего функционала при большей производительности, только в таком случае есть смысл ее мерить, притом разница в результатах должна быть значительная. К сожалению эта гонка теперь сводится к кто быстрее выведет echo «Hello World».
Хех, какой вы хитрый ход сделали.
Согласен тестировать Hello world нет смысла, так(!) как делаете это вы. Ваш так называемый «фреймворк» можно свести к нескольким строкам кода, вот так например twitto.org/
Вы берете Full stack framework против обычного вызова метода (new $class)->$method(); и выдаете это за тест. Как раз Hello world если сравнивается на сайтах фреймворков то сравнивается типичная инициализация фреймворка включая самую отсылку контента клиенту. Т.е. var_dump(new Application) и var_dump(new Phalcon\DI\FactoryDefault) разницу видите? В вашем Application даже роутинга нет по сути. Т.е. Вы ждете от фреймворка как сами написали чтобы у него были Events и DI и роутинг, но сами это в свой Application не включили))) и сравниваете производительность))
Тогда сравните уже мой handmade framework против вашего: ?php die('Hello world'); И кстати мне его легче расширить чем вам свой)))
Согласен тестировать Hello world нет смысла, так(!) как делаете это вы. Ваш так называемый «фреймворк» можно свести к нескольким строкам кода, вот так например twitto.org/
Вы берете Full stack framework против обычного вызова метода (new $class)->$method(); и выдаете это за тест. Как раз Hello world если сравнивается на сайтах фреймворков то сравнивается типичная инициализация фреймворка включая самую отсылку контента клиенту. Т.е. var_dump(new Application) и var_dump(new Phalcon\DI\FactoryDefault) разницу видите? В вашем Application даже роутинга нет по сути. Т.е. Вы ждете от фреймворка как сами написали чтобы у него были Events и DI и роутинг, но сами это в свой Application не включили))) и сравниваете производительность))
Тогда сравните уже мой handmade framework против вашего: ?php die('Hello world'); И кстати мне его легче расширить чем вам свой)))
Посмотрите результаты профайлинга. Я не просто так написал о полезной нагрузке.
О че вы конкретно говорите?
Профайлер не показывает DI\FactoryDefault, хотя там каждый раз создается больше 20 объектов. В общем Phalcon приложение каждый раз создает 25-30 объектов для full stack приложения, ваше же приложение создает 3 объекта, разницу чувствуете? Причем объекты не просто создаются а создаются с вычислениями это request, router, url, посылаются eventы при короче весь процесс. У вас же просто explode строки и вызов метода, больше ничего нет!!!
Поэтому если сравнить die('Hello world') и ваш App->run() это может претендовать на объективность, но никак не PhalconApp vs explode($_SERVER['REQUEST_URI']); $class->$method();
Профайлер не показывает DI\FactoryDefault, хотя там каждый раз создается больше 20 объектов. В общем Phalcon приложение каждый раз создает 25-30 объектов для full stack приложения, ваше же приложение создает 3 объекта, разницу чувствуете? Причем объекты не просто создаются а создаются с вычислениями это request, router, url, посылаются eventы при короче весь процесс. У вас же просто explode строки и вызов метода, больше ничего нет!!!
Поэтому если сравнить die('Hello world') и ваш App->run() это может претендовать на объективность, но никак не PhalconApp vs explode($_SERVER['REQUEST_URI']); $class->$method();
Результат одинаков, там может быть создано сколько угодно много объектов они не создают полезную нагрузку в тесте Hello World. Если бы это был тест который смог показать во всей красе возможности фреймворка, скорость работы его структур и логики, вопроса не возникло бы. Любое маломальское приложение с бизнес логикой и данными показало бы более менее реальные результаты, нежели выбор кто скажет «Привет!»
Sign up to leave a comment.
Так ли быстр ваш Framework или хватит тестировать производительность Нello World