PHP, chroot & opcache – Mateusz matipl Kamiński

W odległych czasach przed PHP 5.2 (listopadem 2006) biblioteki w PHP były małe, frameworki dla PHP prawie nie istniały, dopiero tworzył się Zend Framework 1.0. A aplikacje PHP najczęściej wykorzystywały jeden wzorzec MVC, jeśli w ogóle były tworzone obiektowo.

Aby PHP w tamtym czasie było szybkie nie potrzeba było wiele (głównie I/O bazy). Ale czas zaczął niesamowicie szybko biec, Internet stawał się coraz popularniejszy, pojawiły się przeglądarki mobilne. Tym samym powstawało coraz więcej narzędzi, bibliotek, dodatków, a sama ilość żądań rosła niesamowicie. Pojawił się Zend Framework 2 (wrzesień 2012) oraz Symfony 2 (lipiec 2011), a wraz z nimi tysiące plików PHP potrzebne tylko do jednej aplikacji.
Dla przykładu Symfony 3.4 to 50 MB danych umieszczonych w prawie 9 tysiącach plików.

W dużym skrócie, bo już kiedyś o tym wspominałem, PHP nie był w stanie szybko ogarniać dostępu do tylu plików na raz, przy każdym wykonaniu kodu, przy każdym wywołaniu żądania o aplikację internetową musiał dysku odpytać o wszelkie potrzebne kody źródłowe. Tworzenie cache całego serwisu (do HTML) było tylko pewnym obejściem problemu, ale nie jego rozwiązaniem.

Tak powstały akceleratory PHP, a bardzo szybko dominację na rynku zdobył opcache, który wraz z wersją PHP 5.5.0 został na stałe dołączony do silnika. Niestety od samego początku miał jedną wadę w połączeniu z php-fpm – nie był przygotowany na chroot’owanie.

Na poziomie php-fpm silnik nie wiedział już jaki jest główny katalog, dla niego głównym katalogiem był katalog bieżący. Na przykład, mamy aplikację w katalogu /var/www/app.domain.com/docroot, z włączonym chrootem, dla PHP-FPM i opcache widoczny jest wyłącznie /docroot, a jeszcze częściej sam /.

Korzystanie z chroot (czyli funkcji, aby aplikacje wzajemnie na siebie nie oddziaływały) powodowało, że nie mogliśmy korzystać z opcache. Dlaczego? Opcache powodował tworzenie takich samych skrótów dla różnych aplikacji (np. WordPress, ZF, Sf przenikały się wzajemnie powodując błędy).

Całe szczęście core team wraz z wersją PHP 7.0.14 (grudzień 2016) dodał parametr konfiguracyjny opcache.validate_root, którego włączenie sprawia zapobieganie kolizjom nazw w chroot oraz faktycznym chroot, również z poziomu php-fpm.

opcache.validate_root = 1

1	opcache.validate_root = 1

I w końcu, można od PHP 7.0.14 cieszyć się chroot’em oraz opcache.

PHP RFC: Typed Properties 2.0

Przy okazji wspomnę o ważnym RFC, bo nie każdy śledzi mojego Twittera. Właśnie co został zaakceptowany RFC Typed Properties 2.0 do rdzenia PHP. W wersji PHP 7.4 będzie można jeszcze bardziej odstawić na bok phpDoc czy annotacje. W dzisiejszym świecie PHP dla metod można spokojnie odpuścić sobie /** */, ponieważ na etapie definiowania można powiedzieć jakich typów mają być parametry, czy jakiego typu jest zwrotka z metody. Niestety obecnie nadal trzeba pisać tak:

class User {
    /** @var int $id */
    private $id;
    /** @var string $name */
    private $name;
 
    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }
 ...
}

class User {

/** @var int $id */

private $id;

/** @var string $name */

private $name;

public function __construct(int $id, string $name) {

$this->id = $id;

$this->name = $name;

}

...

}

Ale już za rok będziemy mieli pewną standaryzację w kodzie mogąc definiować typy właściwości klasy wprost:

class User {
    public int $id;
    public string $name;
 
    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }
 ...
}

class User {

public int $id;

public string $name;

public function __construct(int $id, string $name) {

$this->id = $id;

$this->name = $name;

}

...

}

Więcej o zmianie poczytacie w uzasadnieniu Boba Weinanda.

PHP RFC: Typed Properties 2.0

Related