Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
Кажется я начал понимать, как альтернативная реализация PHP, на виртуальной машине, написанной на каком-либо другом языке, может быть быстрее, чем нативная реализация PHP.
А действительно, глобально парни за дело взялись. С задором.
А действительно, глобально парни за дело взялись. С задором.
альтернативная реализация PHP, на виртуальной машине, написанной на каком-либо другом языке, может быть быстрее, чем нативная реализация PHP.Вы под «PHP» подразумеваете интерпретатор языка PHP или приложения, написанные на языке PHP? Потому что и ВМ, и интерпретатор PHP, как я понимаю, оба написаны на С(++).
Будет здорово, если они изменят основной bottleneck PHP — умирать после каждого запроса, как в недавнем ReactPHP. Конечно, это куча работы, это будет опционально, но если это будет уже в самом PHP с должной поддержкой, то люди начнут перестраиваться.
Я думаю, что максимум, что можно сделать без переписывания кода это доработать ядро + менеджер процессов. А именно, сделать возможность хранить в памяти скомпилированный код, а после выполнения очередного запроса очищать память. Соответственно, придется только вручную управлять сбросом кеша кода при его изменении.
Так и работает OPCache
Возможность хранить в памяти даже не скомпилированный код (байткод т.е.), а сущности классов и функций, вот это невозможно сделать в пхп из-за его динамизма, когда например тело класса может поменяться, например в extends стоит название класса, который грузится через загрузчик классов, загрузчик классов может в разных ситуациях грузить физически разные классы под одним названием, с разными методами и телом. Из этого выливается то, что при каждом запросе пхп формирует каждый класс заново, на что уходит тоже много времени.
вы можете отключить это в opcache, и единыжды загруженный кэш до релоада сервера не будет меняться. Собственно это даже рекомендуется для продакшен экружения, ибо позяоляет не обращаться лишний раз к файловой системе за проверками.
Собственно то что вы описываете не является сейчас узким местом. Узкое место это парсинг аргументов, выделение памяти, вызовы функций и т.д.
Собственно то что вы описываете не является сейчас узким местом. Узкое место это парсинг аргументов, выделение памяти, вызовы функций и т.д.
Если включается полное кеширование, то происходит всего лишь: поиск кеша по имени файла -> его загрузка без обращения к файлу. Однако загружается лишь байткод, из байткода еще нужно построить тело классов и функций, нет возможности держать классы и функции уже загруженными в разделяемой памяти.
Вызовы и выделение памяти является также узким местом, я не спорю. На счет парсинга аргументов не совсем понимаю, проблема скорости парсера? Зачем над ней работать если есть кешер байткода.
Вызовы и выделение памяти является также узким местом, я не спорю. На счет парсинга аргументов не совсем понимаю, проблема скорости парсера? Зачем над ней работать если есть кешер байткода.
Так у вас же есть ReactPHP, php-cli, php-pm и т.д. Причем тут ядро? Изменения в ядре помогут ускорить выполнение всего этого чуда, а умирать приложению после каждого запроса или передавать в воркеры и т.д. это уже вам решать. Так что это проблема не zend engine или php в целом, а конкретно инструментов. Вы уже сейчас можете взять тот же reactphp и писать на нем в стиле node.js или twisted.
По поводу же «умирать», opcache как раз решает эту проблему. Если его настроить, у вас оверхэд на старт будет минимальным.
По поводу же «умирать», opcache как раз решает эту проблему. Если его настроить, у вас оверхэд на старт будет минимальным.
Кеш байткода как раз не решает проблему умирания, он только уменьшает затраты на лексический разбор кода. Скрипт все равно вынужден инициализироваться, загружать фреймворк, создавать его фабрики, объекты, и т.п, включая сборщики запросов для разных ORM и прочих моделей, драйверы кеша и базы данных, и уж потом прогонять по всей созданной структуре данных параметры запроса, передавая результат в шаблонизатор, который тоже предварительно должен быть инициализирован. После выполнения запроса все эти объекты оказываются не у дел и уничтожаются. В этом вся суть «создан умирать», в отличие от полноценной асинхронной архитектуры, где окружение инициализируется один раз и живет постоянно (создавая риски для утечек памяти, но это уже совсем другая история).
Опять же, это проблема не php а инструментов. В php есть реализация и event loop, есть многопоточность (пусть и не из коробки, но и в js ее из коробки нету)…
Многопоточность не относится к проблеме умирания. Выходом из проблемы умирания является демонизация работающего php-сценария. Для этого есть соответствующие решения. Но здесь как раз на передний план вылезают такие элементы ядра, как менеджер памяти и эффективный сборщик мусора.
Со сборкой мусора проблем последние года два я не особо наблюдал если честно, демоны-воркеры работают месяцами и не текут. А вот менеджмент памяти да, но это так же собираются рефакторить.
Сборка мусора, все же, отнимает существенную долю процессорного времени, порядка нескольких процентов. Его опимизация и рефакторинг, а так же настройка, могут повлиять на производительность и поведение сервера. Для примера, настройка по умолчанию сборки мусора в высоконагруженном потоке nodejs (порядка 1000 хитов в секунду) вызывает периодичесике пики 100% нагрузки. У php, насколько мне известно, сборка мусора основана на лимите ссылок. Хотелось бы получить больше информации об этом аспекте работы php на реальных проектах, если есть такой практический опыт.
Используйте не php. Там это уже давно так :] А пока в php от cgi модели не отойдут так все и будет работать.
Ну, я уже давно и не использую. Перешёл на Go.
Я с вас удивляюсь. Что мешает взять и отойти-то? Какое принципиальное ограничение?
Официально не поддерживается. Технически все php ПО работает по классической CGI модели. Там есть конечно костыли и подпорки которые это как-то улучшают, но перехода к FastCGI там даже не пахнет, так-как в этом случае придется менять принятые подходы к разработке на php.
Вы не ответили на мой вопрос. Что вам мешает написать настоящий FastCGI-сервер на PHP? Изучить спецификацию и написать?
Насколько я знаю попытки были. Но ничем хорошим они насколько я понимаю не закончились. Так-как php сам по себе в своей модели подразумевает только достаточно короткий цикл выполнения и смерть. Так что в случае долгоживущих процессов вылезут утечки памяти и фиговая работа сборщика мусора.
Во-первых, в PHP относительно недавно появился новый, годный сборщик мусора и демоны на PHP работают у нас неделями (их приходится перезагружать, но совершенно по другой причине).
Во-вторых, течёт не сам PHP (это редкость), а всякие поделки с PECL, а их можно не использовать.
Во-вторых, течёт не сам PHP (это редкость), а всякие поделки с PECL, а их можно не использовать.
Во-первых на данный момент нет официальной спеки на FastCGI у php. Во вторых те самые поделки из PECL часто нужны. И да эта же проблема мешает везде использовать php в паре чем-то отличным от mpm-fork в apache.
Да о чём вы говорите? Какой официальной спеки? FastCGI — открытый серверный протокол. Прочитайте и реализуйте на PHP сервер. Если поделки из PECL нужны, то проверьте, вдруг вам повезло и нужные не текут. А если текут, ничего не мешает написать свои или исправить существующие.
Да о чём вы говорите? Какой официальной спеки?
Я про разработчиков php имею ввиду. А что вы там сами на ваяете это ваше личное дело, только будет проблема с переносимостью и сопровождением вашего ПО.
FastCGI — открытый серверный протокол. Прочитайте и реализуйте на PHP сервер.
Я в курсе что он открытый. Вопрос именно в том что в этом случае вы создаете свое уникальное ПО. Которое никем кроме вас не будет поддерживаться в отличии к примеру от WSGI или PSGI которые стандартизированы.
Я вам как бы хочу мысль донести, что пока нет официальной поддержки для приложений по типу WSGI или PSGI, от того что на php можно сделать FastCGI демон, смысла никакого.
Ну вы знаете, вообще программисты только и делают, что создают своё уникальное ПО. В этом и заключается суть профессии.
Хороший программист, не создает проблемы тем кто будет эксплуатировать его ПО на ровном месте. Если есть штатный метод запуска, то и его и стоит использовать. Либо продвигать стандарт, а не заниматься стоянием в гамаке.
Конечно не создаёт. Только я не вижу как создание собственной реализации FastCGI создаёт проблемы. А вы рассматриваете это так, как будто одно вытекает из другого. Если вам нужно создать выскопроизводительный проект и скорость обработки запросов интерпретатором PHP ваше узкое место, собственный FastCGI — то, что необходимо сделать. Никаких проблем я тут не вижу.
Конечно не создаёт. Только я не вижу как создание собственной реализации FastCGI создаёт проблемы.
Создает. Для того чтобы запустить ваше приложение, стандартный php хостинг не подойдет. Там просто нет такой опции. Т.е. это надо будет брать VPS и настраивать там под ваше ПО. Так-как стандарта под FastCGI на данный момент в php нет.
Если вам нужно создать выскопроизводительный проект и скорость обработки запросов интерпретатором PHP ваше узкое место, собственный FastCGI — то, что необходимо сделать.
Тут есть ровно два противоречивых слова выскопроизводительный и PHP. Все эти рефакторинги, создание отдельных трансляторов, компиляторов php не от хорошей жизни.
И замечу, что в остальных языках, будь то java, perl, python, ruby есть стандартные методы взаимодействия веб-сервера с приложением. Это позволяет под них делать хостинги и хорошо повторяемые инсталляции.
Создает. Для того чтобы запустить ваше приложение, стандартный php хостинг не подойдет. Там просто нет такой опции. Т.е. это надо будет брать VPS и настраивать там под ваше ПО.Какой хостинг вы о чём? Какие проблемы с производительностью у сайтиков на шаред-хостинге?
Тут есть ровно два противоречивых слова выскопроизводительный и PHP. Все эти рефакторинги, создание отдельных трансляторов, компиляторов php не от хорошей жизни.Нет тут никакого противоречия. Вполне удаётся создавать такие проекты и на PHP. Рефакторинг есть везде, а создание компиляторов и интерпретаторов — естественный процесс эволюции, он у любого интерпретируемого языка происходит. Посмотрите на Пайтон (PyPy, Cython, Jython), Джаву (Dalvik), Руби (JRuby, Rubinius, MagLev), ДжаваСкрипт (V8, SpiderMonkey) и так далее.
Какой хостинг вы о чём? Какие проблемы с производительностью у сайтиков на шаред-хостинге?
Очень часто ПО начинает свой путь с сайтега на шаред-хостинге.
Нет тут никакого противоречия. Вполне удаётся создавать такие проекты и на PHP.
Угу. А потом начинается, рефакторинг и прочее.
Рефакторинг есть везде, а создание компиляторов и интерпретаторов — естественный процесс эволюции, он у любого интерпретируемого языка происходит. Посмотрите на Пайтон (PyPy, Cython, Jython), Джаву (Dalvik), Руби (JRuby, Rubinius, MagLev), ДжаваСкрипт (V8, SpiderMonkey) и так далее.
А что мне на них смотреть? Еще раз вам говорю, на данный момент в php нет стандартного метода разработки FastCGI приложений. Ни один существующий фреймворк этого не умеет и уметь не может. Так-как в стандартной модели работы веб-приложения на php, FastCGI нет. То что вы можете сделать свой велосипед я верю.
если это какой-то хоть сколько нибудь серьезный проект, но начинает он свой путь хотя бы с vds баксов за 5, а иногда сразу с aws и прочих облаков.
Что до рефакторингов, это нормальная часть разработки. Без рефакторинга писать что-то серььезное с течением времени становится все сложнее и сложнее.
Возьмите ReactPHP, его должно хватить для реализации того, о чем вы говорите. Запускается он как демон, можно на него проксировать запросы с nginx, для него есть биндинги фреймворков на базе HttpKernel, а это Symfony/Silex/Laravel.
Что до рефакторингов, это нормальная часть разработки. Без рефакторинга писать что-то серььезное с течением времени становится все сложнее и сложнее.
Возьмите ReactPHP, его должно хватить для реализации того, о чем вы говорите. Запускается он как демон, можно на него проксировать запросы с nginx, для него есть биндинги фреймворков на базе HttpKernel, а это Symfony/Silex/Laravel.
Что до рефакторингов, это нормальная часть разработки. Без рефакторинга писать что-то серььезное с течением времени становится все сложнее и сложнее.
Проблема в том что если изначально выбрана плохая арихитектура или не удачный язык. То все будет плохо.
Возьмите ReactPHP, его должно хватить для реализации того, о чем вы говорите. Запускается он как демон, можно на него проксировать запросы с nginx, для него есть биндинги фреймворков на базе HttpKernel, а это Symfony/Silex/Laravel.
Это не стандарт. Вы сами отлично должны это понимать. Плюс вот сейчас все что делается на этом поприще никак в официальную часть php не входит. Да на любом языке можно написать все что угодно. Вопрос трудоемкости. Я не вижу смысла брать для больших проектов php. Просто в силу самого php.
Любой другой инструмент так же не входит в стандарт, так что, его использовать уже нельзя? это глупо. В python так же нету подобных вещей из коробки, но есть twisted, который является дефакто-стандартом для подобных задач.
Вы слишком привязываетесь к слову «стандарт». Наличие из коробки не всем нужно, а решения есть.
Вы слишком привязываетесь к слову «стандарт». Наличие из коробки не всем нужно, а решения есть.
Для веба в Python как раз таки есть стандарт WSGI. У php тоже есть свой, но с CGI-моделью.
Вы так говорите, как будто это данность свыше и ничего менять не нужно. Twisted и WSCGI занимаются всё-таки разными вещами.
Вы так говорите, как будто это данность свыше и ничего менять не нужно. Twisted и WSCGI занимаются всё-таки разными вещами.
Я говорю, что сначала надо подумать, что это даст и как это потом сопровождать. Я видел кучу ПО сделанного программистами, которое сложно сопровождать и ставить. Причем ПО может быть сколь угодно хорошим.
Это вопрос культуры разработки, этого хватает с любыми языками и технологиями.
Я не против того чтобы думать. У нас с вами специфика разная, я так понял. Я участвую в разработке выскононагруженного софта, срок жизни которого с десяток лет, а вы занимаетесь небольшими сайтами, я так понял.
Отсюда и недопонимание.
Отсюда и недопонимание.
У нас с вами специфика разная, я так понял. Я участвую в разработке выскононагруженного софта, срок жизни которого с десяток лет, а вы занимаетесь небольшими сайтами, я так понял.
Высоконагруженный софт на PHP? Не завидую правда. Посмотрите на что в итоге это выливается на примере twitter и e-bay.
twitter — раньше ruby теперь scala+ruby, ebay насколько я помню так же не на php написан. И причем тут php?
У твиттера больше java чем scala. ebay был написан на perl в результате сейчас нагруженные части на c++/java. Это пример как люди в итоге отказываются от тех средств что не предназначенные под высокие нагрузки. А те кто остаются с php начинают писать костыли. Смотрим hip-hop и прочее.
Это нормально. Лучше потратить n времени написал проект на php/ruby и т.д, запустить бизнес раньше и получать прибыль раньше, чем потратить 3n времени, написать все круто на c++/d и утратить тот момент, когда проект взлетит. Если проект выстреливает — можно уже заниматься переписью узких мест. Это вполне нормальное явление, темболее что проектов масштаба twitter/facebook и т.д. не так уж и много.
Да нет, нормально всё. Чаще упирается в базу, а не в PHP.
Да забудте вы про shared, если там проблемы с производительностью, то надо переходить на отдельную виртуалку, а не писать собственный FastCGI.
Если что-то решает ваши проблемы, надо это использовать.
А потом начинается, рефакторинг и прочее.Рефактиринг будет всегда, если проект живёт длительное время, это никакая не проблема, а нормальный рабочий процесс.
А что мне на них смотреть? Еще раз вам говорю, на данный момент в php нет стандартного метода разработки FastCGI приложений. Ни один существующий фреймворк этого не умеет и уметь не может.Ну и что? Все эти фреймворки (как и сам PHP) начаты как велосипед, что с того-то? Как будто это аргумент какой-то. php-fpm тоже начинался как патч одного человека к PHP и существовал отдельно. Ничего, теперь стандарт.
Если что-то решает ваши проблемы, надо это использовать.
Да забудте вы про shared, если там проблемы с производительностью, то надо переходить на отдельную виртуалку, а не писать собственный FastCGI.
Вот и я про то же. Очень часто можно вообще не писать свой велосипед.
Рефактиринг будет всегда, если проект живёт длительное время, это никакая не проблема, а нормальный рабочий процесс.
Конечно, только вот можно или сделать себе удобно или не удобно.
Ну и что? Все эти фреймворки (как и сам PHP) начаты как велосипед, что с того-то? Как будто это аргумент какой-то. php-fpm тоже начинался как патч одного человека к PHP и существовал отдельно. Ничего, теперь стандарт.
То что переход с CGI модели на FastCGI модель дело очень не быстрое. И смысла это делать в php сейчас, не вижу. И если у вас уже CGI модель, то перейти на FastCGI будет ой как сложно. Так что на данный момент я бы если мне уж сильно приспичило использовать PHP в FastCGI то я бы взял как раз ReactPHP и биндинг в один из фреймворков.
php-fmp насколько я помню это реализация именно fastcgi сервера. Собственно как мне помниться, развитие этих идей получилось в создании phpdeamon а уже потом в reactphp.
php-fpm не совсем то. Это, конечно, сервер FastCGI, но внутри он запускает PHP в режиме CGI.
php-fpm реализует интерфейс fastcgi для связи с веб-сервером типа nginx или apache, но делает это абсолютно прозрачно для приложения — для него (почти) нет разницы запускается оно как php-fpm, mod_php или просто cgi-«бинарник». php-fpm — оптимизация запуска интерпретатора, но не приложение — на каждый запрос оно полностью инициализируется.
Php-daemon можно использовать как основу для своего fastcgi-сервера (собственно он уже реализован), но просто «скопипастить» вордпресс или джумлу не получится.
Php-daemon можно использовать как основу для своего fastcgi-сервера (собственно он уже реализован), но просто «скопипастить» вордпресс или джумлу не получится.
А что вам мешает на PHP-то написать правильный FastCGI?
The cake is a lie!
У кого-нибудь получилось собрать?
Одна просьба — если что-то революционное делать, то не называть это старым именем. Назовите не PHP NG, а PHN, хотя бы (но не PNG!), чтобы, разыскивая инфу в Гугле на тему нового варианта языка (а будет в Гугле поначалу 10 ссылок), не приходилось вслепую фильтровать для себя из 100 000 000 ссылок про «старый» вариант.
Это не новый вариант языка. Язык никак не изменяется.
From: Dmitry Stogov
I would say it must be 100% compatible at the end, may be with exception for very rare and unclear cases that worked just because of existing implementation. (e.g. mixing foreach and next() on the same array).
Да, это я заметил.
Но, заметьте, по факту изменения серьезные, пусть и не в самом языке, но в том, как код исполняется. Хочется про 100% верить, но… не факт, что так и окажется (не сейчас, а по мере перехода на 5.7 и переносу туда всего многообразия модулей и библиотек). Так что подстраховаться с названием не мешает ))
Но, заметьте, по факту изменения серьезные, пусть и не в самом языке, но в том, как код исполняется. Хочется про 100% верить, но… не факт, что так и окажется (не сейчас, а по мере перехода на 5.7 и переносу туда всего многообразия модулей и библиотек). Так что подстраховаться с названием не мешает ))
По сути вас не должна беспокоить внутренняя кухня интерпритатора (ну как, должна но не в контексте ваших приложений), в этом же вся суть. То что не все расширения готовы — ну так 5.7 еще не скоро думаю выйдет, так что время на тестирование и прочее будет.
Довольно серьезные внутренние изменения в Zend VM были, например, между 5.3 и 5.4. Не думаю, что вы это заметили, если только не смотрели в исходный код ;)
Главное это наличие Thread из коробки под обе платформы. Это позволит писать standalone приложения и выведет PHP с уровня запрос-приложение, на уровень сервер-приложения. Вообщем прирост скорости и необходимость разработки в многопоточной среде сразу даст мощьный пинок развития всем говнокодерам на PHP… Хотя надо ли это?
Говнокодерам на PHP треды из коробки не помогут, только вызовут больше проблем. А для не говнокодеров на php, они уже давно есть в виде экстеншена.
Последняя сборка 5.5.12 для Windows выдает следующее на мои попытки завести потоки
Fatal error: Class 'Thread' not found in C:\Downloads\daemon.php on line 3
Таким образом приходиться вести разработку только под Linux платформу, а мне (и возможно многим) это может оказаться неудобно.
Fatal error: Class 'Thread' not found in C:\Downloads\daemon.php on line 3
Таким образом приходиться вести разработку только под Linux платформу, а мне (и возможно многим) это может оказаться неудобно.
Не удобно по началу, на самом деле есть масса инструментов облегчающих жизнь, которые под windows просто не запустятся (ансибл, докер), жить с нормальным башем как-то лучше чем с mingw… Да и что уж говорить про git для windows. Я хоть и не поклонник всех этих линуксов, но для работы и конкретно для backend разработки пожалуй лучше особо ничего и нету.
Словом, если вам нужны потоки (именно нужны, а не просто прихоть), то поставите себе линукс или в крайнем случае завернете окружение в виртуальную машину и будете шарить через вагрант, что так же довольно удобно.
Словом, если вам нужны потоки (именно нужны, а не просто прихоть), то поставите себе линукс или в крайнем случае завернете окружение в виртуальную машину и будете шарить через вагрант, что так же довольно удобно.
> Не удобно по началу, на самом деле есть масса инструментов облегчающих жизнь, которые под windows просто не запустятся…
Это тема отдельного разговора, а мы тут про PHP.
> Словом, если вам нужны потоки (именно нужны, а не просто прихоть), то поставите себе линукс
Понятно, что можно поставить себе Linux и даже начать на работу летать на аэроплане, но сейчас ситуация такая,
что это проблема и у нее нет решения под мое окружение.
> в крайнем случае завернете окружение в виртуальную машину и будете шарить через вагрант, что так же довольно удобно.
Да, этот обходной прием сейчас часто и приходиться использовать, а это требует все большего количества инструментов и развития все более сложной инфраструктуры. А это требует поддержания еще и конфигурации, а это требует отдельного Configuration Manager.
Это тема отдельного разговора, а мы тут про PHP.
> Словом, если вам нужны потоки (именно нужны, а не просто прихоть), то поставите себе линукс
Понятно, что можно поставить себе Linux и даже начать на работу летать на аэроплане, но сейчас ситуация такая,
что это проблема и у нее нет решения под мое окружение.
> в крайнем случае завернете окружение в виртуальную машину и будете шарить через вагрант, что так же довольно удобно.
Да, этот обходной прием сейчас часто и приходиться использовать, а это требует все большего количества инструментов и развития все более сложной инфраструктуры. А это требует поддержания еще и конфигурации, а это требует отдельного Configuration Manager.
Да и что уж говорить про git для windows.
И какие же с ним проблемы? (давным давно использую и как-то не замечал проблем)
PHP6 и всякие попытки модернизации терпели фиаско. Им как бы ничего больше не остаётся, кроме как наращивать производительность.
Жаль что поддержки mysqli нет еще. Поддержка deprecated модуля mysql есть, а mysqli нет :(
Вы можете помочь проекту. :) Там портирование в основном сводится к замене ряда вызовов на другие по ряду правил. Если сравнить изменения в «старом» и «новом» ext/mysql — можно портировать mysqli по аналогии (разве что еще в каком-то из портированных расширений надо подсмотреть, как правильно портировать классы).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP New Generation