to post messages and comments.

← All posts tagged PHP

@Balancer:
PHP

Вот, что значит, много лет писать большую систему. Сейчас решил переиначить древний часть древнего околопроцедурного кода на объектный, с цепочками вызовов. Программирую сверху вниз, написал каркас, обработку данных и в конце — запись результата цепочкой объектных вызовов. Запускаю, чтобы посмотреть как обработка пройдёт, ожидая получение ошибки отсутствующих методов на последнем вызове. Опаньки, код проходит и работает. Оказывается, я когда-то давно этот код/объекты написал и с именно таким набором методов :D

@Balancer:

Небольшое обновление теста объектного Фибоначчи: github.com

* Добавил JavaScript. Результат отличный — 2.64 сек. Почти как у Dart'а, лучше, чем у D. Похоже, сегодня это самый быстрый скриптовый язык.

Обновил:

* PHP до 7.1.0. Стал чуть-чуть быстрее, 50.6 против 58.0 у t.0.13

* HHVM практически не изменился. 24.5 против 25.0

* Python до 3.5.2 и 2.7.12. Удивительно, но он стал ещё медленнее — 170 и 153 сек. против прежних 145/129.

@Balancer:

Вот интересно.
— Основная моя деятельность в работе/собственных проектах/etc — программирование на PHP.
— Я общаюсь на огромном числе разных форумов и социальных сетей по самым разным тематикам. И по программированию в том числе.
— Но я никогда почти не общаюсь на форумах PHP-шников.

Вот, реально, последний раз вылезал летом 2015-го. С одним сообщением на всех форумах (хотел обсудить какой-то вопрос). Перед этим — ещё где-то за год до того...

И, вот, вчера, год спустя, опять на 4 популярных форума тему мне интересную поднял. Результат обескураживает. В каждом сообщении сквозит какое-то самомнение, завышенное ЧСВ и при этом половина сообщений вообще не по теме, как будто авторы вообще не читают текст, а пишут из какого-то своего мира китайской комнаты, реагирующей на ключевые слова.

Пользы — полный ноль. Настроения от общения — никакого. Танцпольный срач на ЛОРе и то на порядок приятнее :) И так — на всех форумах, блин.

Это я какой-то не такой или остальные PHP-шники какие-то не такие? :D

@Balancer:

Попалось очень интересное решение, которое процентов на 80 пересекается с моими идеями и разработками:

getgrav.org

— CMS базируется на плоских файлах в Markdown формате (для ускорения опционально возможно кеширование «поверх»).
— Хотя наличествуют и традиционные способы установки, рулит реализация всего на Composer.
— Большое количество плагинов и тем (Twig).
— Запускается в базовом варианте сразу, без всякого конфигурирования.
— Есть свой пакетный менеджер для расширений/тем.
— Расширения/темы можно ставить через админку (хотя первый раз она ставится отдельным пакетом).
— Мультисайты, многоязыковость, ЧПУ, роутинг, редиректы
— Система пользователей и прав (хотя не разбирался, есть ли возможность коллективной работы).
— Контент может браться из Git, SVN, Dropbox и других. В т.ч., например, текст страниц может быть прямо на GitHub.

Моя идея «поправил файл дома, он через SparkleShare автоматом ушёл на GitHub, GitHub дёрнул сайт и вот страница уже на сайте», т.е. «правлю Markdown-файл дома в файловой системе — обновляется удалённый сайт» тут, кажется, уже работает.

Забавно, что формат метаданных в Markdown практически совпадает с моим :) Т.е. большинство моих тестовых страничек в этой CMS будут работать как есть.

Небольшие нестыковки с моей системой по структуре имён файлов, расположению картинок и т.п. У меня логичнее :)

Надо будет подумать. То ли эту CMS как есть на мои новые сайты ставить, то ли просто в роли бэкенда/миддлэнда (админка, редактор файлов, благо, он хорошо сделан, а фронт уже мой). В любом случае система заслуживает внимания :)

@Balancer:

Поиск подстроки в юникодной строке в PHP без учёта регистра через preg_match() с модификаторами "/ui" в 7.5 раз быстрее, чем через mb_stripos(). В одном скрипте тут профилировал, 19.5 тыс. проверок. Так время работы — 0.31 сек. против 2.3 сек :)

@Balancer:

То, что в PHP7 зарезервировали Null, не позволяя использовать в именах классов — ещё пережить можно. Но вот за намерения зарезервировать в будущем Object — надо руки отрывать. Это, по-моему, самый сильный удар по моей обратной совместимости за всю историю PHP :) Хорошо ещё, что я ленивый, и на namespaces перехожу очень медленно, так что классы bors_object в B2\Object успел поменять только в не массовом коде. Пришлось делать рефакторинг на использование B2\Nil и B2\Obj.

@Balancer:

Давно не обновлял цифры производительности в «Объектном Фибоначчи»: github.com

PHP7 обошёл и Ruby, и Python. Но по-прежнему здорово проигрывает HHVM. Есть и другие, хоть и менее заметные перестановки. Думаю, надо выкроить пол-часика, изучить поверхностно Rust и слепить тест для него. На днях попробую пощупать.

@Balancer:

Перевёл на пробу один тестовый контейнер на PHP7. На php-5.5.9 медианное время отклика типовой среднего веса динамической страницы было 75мс, минимальное — 65мс. На php-7.0.4 стало 59мс и 28мс, соответственно. Это в один поток.

В 5 потоков — с 173/73 мс до 65/37мс.

В общем, разница очень заметная :) Надо будет всё оттестировать и переводить боевые сервера...

@Balancer:

Фигня какая-то. Делаю тут для изучения несложную задачку (взять html, подсунуть параметр из GET-запроса) на Golang. В результате, запросов в секунду:

* PHP (голый) — до 12000
* Golang/Revel — до 8700
* Golang/Gin-gonic — до 4800

Удивительно, во-первых, что Revel быстрее Gin'а, обычно считается наоборот. Но это ладно.

Вот каким макаром PHP получается быстрее — не понимаю. Т.е. цифра вообще какая-то нереальная в моём привычном мировоззрении... При чём не 7.0 какой-нибудь или hhvm, а обычный 5.4.45, fpm.

Может, фишка в том, что PHP используется классически, html-код со вставкой, который один раз компилируется и потом берётся из кеша, а golang-фреймворки так не умеют и производят чтение/парсинг на каждом запросе? Или вопрос в оптимизации многоядерности, т.к. у php-fpm уйма инстансов, грузящих все ядра, а у Revel/Gin собственный менеджер и фиг знает, как он там распределяет загрузку?

@Balancer:

Походу, перескачу через версию PHP-5.4. В кои-то веки не приходится тащить всякое Legacy с кривохостингами, а совсем старое умирает с прекращением поддержки PHP-5.3, за который я долго держался в разработке. Ну и раз всё равно уходим от PHP-5.3, то не на PHP-5.4, а сразу на PHP-5.5 с его генераторами и сопрограммами. Больно вкусные фишки, чтобы не перескочить через версию...

@Balancer:

Вчера попробовал прикрутить к своему фреймворку фреймворк Lumen (на базе Laravel 5). В основном — с целью попытки освоить миграции БД. Что удивительно, прикрутилось почти сразу, в несколько строк кода. Забавно, что функции config() и config_set() в обоих фреймворках оказались одного формата, так что мой, загруженный после, работает с ними без нареканий.

Минус у Lumen/Laravel 5 пока только в том, что миграции не работают «из коробки» с пакетами Composer. Повозился немного, разобрался с форматом команд у artisan, прикрутил генерацию заготовки под миграцию (package:make:migration). Загрузка миграции вручную, с указанием пути, работает. Надо придумать, как автоматизировать совсем. Удаление миграции из пакета работает «из коробки».

В общем, нужно теперь будет осваивать. И есть мысль переписать свою консольную утилитку bors на использование artisan. И, вообще, можно интегрироваться с Lumen. Похоже, это не составит труда. А в качестве бонуса — огромное коммьюнити с массой пакетов.

@Balancer:

Вот, наконец попалась вполне логичная статья по работе через Docker связки nginx+php-fpm+mysql. Именно в рамках Docker-идеологии. Без модной темы запихивания всего LEMP в один Docker-образ.

newmediacampaigns.com

@Balancer:

/me Слоупок сделал сегодня на своих машинах, наконец, opcache.enable=1 && apt-get purge php5-xcache && emerge -C xcache. PHP Opcache явно созрел и даже работает быстрее, чем xcache.

@Balancer:

Замерил скорость hhvm 3.5.1 на «объектом Фибоначчи». Получил утроение скорости по сравнению с php 5.5 и hhvm 2.x Это уже очень неплохо. Надо думать о тестах на серверах под нагрузкой.

@Balancer:

Продолжаю постигать дзен Docker'а. Поток мыслей по теме :)

Вот nginx. Отлично контейнеризуется. Делаем минимальный образ и запускаем только его. Официальный nginx весит 100Мб... Многовато, но если хотя бы на десяток контейнеров поделить — копейки. А вот автоматически dockerfile/nginx весит уже аж 500Мб. Посмотрел — они аж из целой Ubuntu его собирают! Вот нафига попу гармонь? Это ж снова попытка сделать из Docker оригинальную LXC! А нужно-то только один голый nginx иметь. При запуске контейнера указать персистентные конфиг и docroot. И всё, больше ничего не нужно. Даже 100Мб — это дофига.

Дальше — больше. nginx'у нужен php-fpm. Прекрасно, он пашет по сетевому интерфейсу, отлично конфигурится в той же Ubuntu (хоть индивидуально модули задавай). То есть, логика простая — запускаем контейнер с nginx, запускаем контейнер с php-fpm, каждый сам по себе, всем хорошо. С обновлениями просто, каждый обновляется отдельно (если я правильно понял, достаточно периодически docker pull делать — и всё). Фигушки. Нет вообще в docker hub'е голого php-fpm! Только в паре с nginx (в лучшем случае, а то целые комбайны). Такое впечатление, что народ сути Docker не только вообще не понимает, но и подумать на этот счёт не хочет :)

Судя по всему, придётся заводить самому в хабе минимальный образ с php-fpm, да ещё писать для народа идеологический how-to :)

@Balancer:

GitHub такой GitHub... Пошёл разворачивать свою PHP-библиотеку с зависимостями, взял и обломал меня: «over the API rate limit». Это неожиданный удар по Composer, однако...

@Balancer:

Уф. Решил в общих чертах главную концептуальную проблему фреймворка, не дававшую покоя с момента решения перехода на Composer. Придумал, как растащить по Composer-пакетам всякие assets (jQuery-плагины, Bootstrap'ы и т.п.). Сегодня слепил первый тест. Работает :D Можно будет отказаться от лепления всех сторонних библиотек в одну репо-кучу. Правда, с bower не совместимо, придётся писать фабрику-конвертер bower в composer для многих популярных библиотек.
~~~

@Balancer:

Тестирую тут hhvm под своим объектным мультиязыковым бенчмарком ( github.com ). И что интересно. Для fib(30) hhvm оказывается на полтора порядка быстрее, чем PHP5.5 (что-то ~1.4 сек против ~50..60 сек.) Но на тестовых fib(40) hhvm оказывается медленнее, чем PHP5.5. (~200 сек. vs 158 сек.)

@Balancer:

О! В Gentoo PHP в слоте 5.5 (5.5.1), оказывается, застабилизировался.

@Balancer:

А неплохой web-сервер для разработки засунули в PHP 5.4. Сейчас прогнал ab, 500 запросов в 20 потоков на Q6600, вышло 611 запросов (phpinfo) в секунду для встроенного сервера при медианном времени отдачи 32мс, а lighttpd+fastcgi на этой же машине — 1521 запрос в секунду при медианном времени 13 мс. Максимальное время — 39мс и 30мс, соответственно. Статика отдаётся 11700 простых файлов в секунду для встроенного в PHP и 15400 в секунду для lighttpd.