Профайлинг PHP приложений

Анализ времени вызовов методов и функций позволяет найти «бутылочное горлышко» в проекте для последующей оптимизации.

Установим XDebug и инструмент для просмотра профайлинг-логов, например KCacheGrind.

apt install php-xdebug kcachegrind

Затем активировуем профайлинг в php.ini (путь до файла зависит от конфигурации веб-сервера):

mcedit /etc/php/7.0/fpm/php.ini

Добавив в конец:

xdebug.profiler_enable = On
xdebug.profiler_output_name="cachegrind.out.%H.%R.%u"

Перезапустим PHP сервер:

service php7.0-fpm reload

Теперь после каждого открытия PHP приложений, в /tmp (по умолчанию) будут создаваться файлы с именем cachegrind.out.ХОСТ.REQUEST_URI.ВРЕМЕННАЯ_МЕТКА.

Эти файлы можно открыть через KCacheGrind.

Как автоматически создавать геттеры и сеттеры

Всевозможную рутину следует автоматизировать. В создании геттеров и сеттеров нет никакой интеллектуальной деятельности, с этим справится простейший алгоритм. В PhpStorm для таких целей существуют генераторы, среди которых есть и генератор геттеров и сеттеров:

ПРАВИЛЬНОЕ решение: But these conflict with your requirements or minimum-stability

Если вы загуглите исправление ошибки Composer «But these conflict with your requirements or minimum-stability», то, вероятнее всего, наткнётесь на совет добавить в composer.json параметр:

"minimum-stability": "dev"

Однако, это только половина решения, но приводящая к тому, что пакеты, имеющие несколько версий (dev, beta, stable), будут ставиться в версии dev (разрабатываемой) с соответствующими нежеланными и неожиданными последствиями и нестабильностью.

Чтобы этого избежать, нужно добавить ещё один параметр — prefer-stable. Он говорит Composer предпочитать стабильные версии пакетов и только в случае, если таковых нет, устанавливать версии, удовлетворяющие заданную минимальную стабильность (в данном случае dev).

Таким образом, чтобы исправить ошибку Composer «But these conflict with your requirements or minimum-stability», необходимо в composer.json добавить параметр prefer-stable в паре с minimum-stability:

{
    ...,
    "require": {
       ...
    },
    "prefer-stable": true,
    "minimum-stability": "dev"
}

Отключаем запуск внешних программ через PHP

В PHP есть ряд функций, с помощью которых можно запускать внешние программы, в т.ч. через шелл.

Это очень полезная возможность при создании сервисов и других приложений посложнее сайтиков.

Но на серверах, на которых работают только типичные сайты (например, на CMF или CMS), данные функции могут быть использованы скрипт-кидди и прочими хакерами, эксплуатирующими уязвимости тех же CMS. И, даже ограничивая поле деятельности сайта в рамках его каталога хоста, с помощью запуска внешних программ разрушительные действия могут вырваться за пределы этой песочницы.

Читать дальше…

Никогда не используйте NULL

Когда мы вместе с клиентами проводим код-ревью, регулярно наблюдаем одну и ту же картину, которую я считаю проблематичной во многих отношениях – использование null в качестве допустимого свойства или возвращаемого значения. Можно же сделать лучше.

Давайте сперва посмотрим общие сценарии использования, а затем обсудим, как можно улучшить код, чтобы сделать его более устойчивым к ошибкам и простым в использовании. Большинство отмеченных проблем становятся особенно заметными, когда ваши исходники использует кто-то ещё.

Для чего это используется

Примером частого сценария использования может быть внедрение дополнительных зависимостей через метод класса:

class SomeLoggingService {
    private $logger = null;

    public function setLogger(Logger $logger) {
        $this->logger = $logger;
    }
}

 

В большинстве случаев logger будет установлен, но кто-то забудет об этом при использовании вашего сервиса. На сцену выходит второй разработчик и пишет новый метод в этом классе, используя свойство $logger. Во время разработки свойство всегда устанавливается и тестируется по соответствующим сценариям использования, так что разработчики забывают проверять на null – очевидно, это станет проблемой при других обстоятельствах. Вы полагаетесь на то, что методы будут вызваны в определённом порядке, который сложно документировать. Метод getLogger(), создающий нулевой логгер по умолчанию, мог бы решить эту проблему, но не гарантировано, поскольку второй разработчик может не знать об этом методе и просто использовать свойство.

Читать дальше…

Суперскоростной Symfony с помощью nginx

Вкратце: поместите обратный прокси-сервер перед вашим приложением (для HTTP-кэширования или с целью балансировки нагрузки), чтобы увеличить его производительность.

Фреймворки, такие как Symfony, потенциально позволяют создавать суперскоростные приложения. Мы уже видели один способ как добиться этого (путём превращения приложения в HTTP сервер), другой способ заключается в установке обратного прокси перед ним.

В данной статье мы возьмём Symfony приложение и увидим, как увеличить его производительность в 140 раз с помощью nginx.

Читать дальше…

Почему PHP-разработчики думают, что MVC – это архитектура приложения?

Ранее я указывал на то, что Model-View-Controller представляет собой паттерн пользовательского интерфейса, а не архитектуру приложения. Но откуда у PHP-разработчиков возникла идея, что MVC – это в первую очередь архитектура? (Это можно сказать обо всех разработчиках серверной части, не только о PHP)

Я одно время думал, что MVC — это архитектура. Даже после прочтения «Каталога шаблонов корпоративных приложений» Фаулера и, несмотря на то, что MVC предназначался для пользовательского интерфейса, я полагал, что всё правильно понял и делаю «приложение пользовательского интерфейса». Но это было не совсем так; правильнее было бы сказать, что я смешивал проблемы пользовательского интерфейса с основой ядра приложения.

Читать дальше…

Асинхронные контроллеры в Symfony

Асинхронное программирование в последние годы стало синонимом высокой производительности в веб-приложениях со стороны сервера. Во многом это связано с возрастающей популярностью изначально асинхронных JavaScript и Node.js.

Как и многие другие вещи, асинхронное программирование не является чем-то новым. Вы можете использовать этот стиль программирования во многих средах, начиная с Python и заканчивая .NET.

В браузере отдельные события, такие как клик мыши, помещаются в цикл обработки событий (см. What the heck is the event loop anyway?, Филип Робертс), а затем события обрабатываются асинхронно без определённой очерёдности: нельзя точно узнать, когда событие клика мыши выполнится.

Ключевое место в асинхронности занимает I/O. В браузерах данное понятие включено начиная с Internet Explorer 5.0 и популяризировано Gmail в 2004 году. Придуманный метод, AJAX, позволил браузерам выполнять запросы к серверу после первоначальной загрузки страницы.

На сервере неблокирующий асинхронный I/O позволяет, например, продолжать выполнять другие задачи, вместо того, чтобы ожидать выполнения долгих запросов к базе данных. Существует много механизмов для обработки потоков асинхронного кода, такие как фьючерсы/promises, генераторы и наблюдатели.

Так что асинхронное программирование не разгоняет ваш компьютер, чтобы получить более высокую производительность. Оно может только помочь компьютеру использовать более эффективно ресурсы путём устранения потерь времени на ожидание.

Асинхронный PHP

Читать дальше…

Защищённые классы

Сегодня у меня была любопытная беседа с Дэвидом Мюрреем об идее защищённых моделей от использования в нежелательных контекстах. Он разрабатывал приложение, у которого есть репозитории, работающие с моделями, и мы подумали, что стоит попробовать защитить модели от непосредственного использования.

Ограничения

PHP не поддерживает такого рода трюки. На самом деле это довольно смехотворная идея – предотвратить вызов класса в определённое время. Но это нечто такое, что можно сделать с помощью подручных средств.

Давайте предположим, что конкретные классы могут быть созданы только в контексте других классов. Мы можем создать только модели Doctrine в репозиториях доктрины, модели Eloquent в Eloquent репозиториях и так далее.

Читать дальше…

Доступ к protected свойствам объектов с общим предком

На днях я понял нечто странное о доступе к protected свойствам. В PHP возможно получить доступ к protected свойствам из других объектов, пока они того же класса, как проиллюстрировано ниже:


<?php

class MyClass 
{
    protected $val;

    public function __construct($newVal = 'default') 
    {
        $this->val = $newVal;
    }

    public function output(MyClass $subject) 
    {
        echo $subject->val, "\n";
    }
}

$obj1 = new MyClass();
$obj2 = new MyClass("hello world");

$obj1->output($obj2);
// Output: hello world

Я всегда думал, что protected позволяет объектам получить доступ к элементам строго от текущего дерева наследования, но не понимал, что это распространяется и на другие экземпляры того же объекта.

Такое поведение работает на свойствах и методах даже тогда, когда область видимость их определяются как private.

На другой день, однако, я понял, что это также работает и для объектов других классов, в которых вы обращаетесь к членам, объявленным в классе с общим предком.

Звучит немного сложно, так что вот пример:

Читать дальше…

Случайности в PHP 7 – ощущаете ли себя удачливым?

1444736085dice

В статье анализируются проблемы, связанные с генерацией случайных чисел, используемых в целях криптографии. PHP 5 не обеспечивает простого механизма для генерации криптографически стойких случайных чисел, в то время как PHP 7 решает это с помощью функций CSPRNG.

Итак, что такое CSPRNG?

Цитируя Википедию, Криптографически стойкий генератор псевдослучайных чисел (Cryptographically Secure Pseudorandom Number Generator) — это генератор псевдослучайных чисел со свойствами, делающими его подходящим для использования в криптографии.

CSPRNG в основном полезен для:

Читать дальше…