Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: matipl, dodany: 24.01.2019 14:45, tagi: php

PHP 7 jest już z nami 3 lata. Właśnie wygaszono PHP 7.0 oraz PHP 5.6, czyli nie są już w żaden sposób wspierane przez społeczność pracującą przy core PHP. Statystyki na podstawie pobrań Composera w połowie 2018 roku mówią, że około 80% to już PHP 7.* – jest dobrze można pomyśleć. Aż tu nagle znajduje się pewien problem…

Phalcon

Nie wiem, czy każdy z Was słyszał o Phalconie – frameworku PHP napisanym w C, kompilowanym jako rozszerzenie PECL. W 2016 roku, kilka miesiący po ukazaniu się PHP 7, został opublikowany Phalcon 3.0 z pełnym wsparciem dla PHP 7.0. Prawie każdy o nim mówił, ponieważ samo użycie PHP 7 przyspieszało aplikacje, a co dopiero pomyśleć gdyby ktoś również korzystał z frameworka, który nie musi za każdym razem ładować setek swoich plików, tylko byłby natywnie dołączany do PHP… Sam byłem zachwycony, ale nie korzystałem.

Trafiła mi się sprawa związana z dłubaniem w aplikacji opartej o Phalcon 3. Wszystko wydawało się super dopóki zostawało sie na poziomie kontrolerów, widoków, podstawowej konfiguracji. Jak chciałem (musiałem) zrobić coś więcej – optymalizacja zarządzania sesją okazało się, że tutaj nie jest kolorowo. Zderzyłem się ze ścianą – Phalcon posiada nikłą dokumentację, moim zdaniem na poziomie Zend Framework 0.*. Jest prosty guide, wygenerowany „phpdoc” na podstawie komentarzy klas i to wszystko. Chciałbyś poznać dokładną listę parametrów np. do Phalcon\Session\Adapter\Libmemcached – bez szans, chciałbyś zoptymalizować sposób łączenia sie z memcached itd. – bez szans. Okazało się, że może jest to dobry framework, ale podstawowa wiedza rozsiana jest po forach internetowych, brak informacji od speców korzystających z niego do czegoś więcej niż CMS-y i proste serwisy. Dla zainteresowanych warto przeczytać książkę Phalcon PHP Framework Documentation po francusku, ale przynosi trochę więcej wiedzy.

PHP Versions Grouped (May 2018)

Problem

Nie wiem czy pamiętacie, ale 2016 rok nie był rokiem PHP 7. Dlaczego? Mało narzędzi poprawnie współpracowało z PHP 7. W samym slniku dużo zostało zmienione i społeczność od PECL-i nie nadążyła. Firmy/Projekty dopiero robiły przymiarki, szczególnie gdy okazywało się, że aplikacje wymagały refactoringu, aby poprawnie działać na PHP 7 (usunięte rozszerzenia i SAPI w PHP 7.0). W pewnym momencie okazało się, że memcached w końcu działa poprawnie z PHP 7 i poszło wszystko do przodu. Również w projektach, w których brałem udział.

Ale. Do tej pory nie spotkałem się z sytuacją, aby memcached nie mógł poprawnie zawiadywać sesjami i stanowił problem (chociaż są nowsze podejścia, np. Redis jak save_handler). Okazuje się, że PHP 7 w połączeniu z memcached w pewnych sytuacjach (duża ilość requestów „AJAX”) może rzucić:

PHP Warning: session_start(): Unable to clear session lock record in (...)

Jeśli mamy wygłuszone błędy (produkcja) to może to pozostać niezauważone albo po prostu zniknąć w czeluściach logów. Tym bardziej, gdy dzieje się sporadycznie. Ale co właściwie się dzieje?

Rozwiązanie

Okazuje się, że podobny problem (wiele zapytań równoległych z JS „psuje” sesje) ma wiele osób w sieci już od 2016 roku, czyli momentu wydania modułu. Oczywiście można byłoby przepisać miejsca, gdzie wykorzystywana jest sesja i lepiej kontrolować przepływ informacji. Ale to zwiększa koszty pracy, jak również może powodować kolejne komplikacje. Nie pomagało w tej sytuacji zamykanie sesji wcześniej (session_write_close()), ani inne wynalazki (np. nowość w PHP 7 session.lazy_write). Okazuje się, że problem jest dość trywialny i dotyczy domyślnej wartości dla memcached.sess_lock_retries, która od początku wersji 3.0 była ustawiona na 5. Wydaje mi się, że niska wartość w połączeniu z PHP 7 i HTTP2 (jeden kanał do całej komunikacji, mniejsze zatory na zapytaniach) spowodowały ujawnienie błędu domyślnej konfiguracji. W połowie 2017 roku ukazał się odpowiedni Pull Request zmieniający domyslną wartość w INI, jak również w samym C

- ; Default is 1000.
- ;memcached.sess_lock_wait_min = 1000;
+ ; Default is 150.
+ ;memcached.sess_lock_wait_min = 150;

; The maximum time, in milliseconds, to wait between session lock attempts.
-; Default is 2000.
-;memcached.sess_lock_wait_max = 2000;
+; Default is 150.
+;memcached.sess_lock_wait_max = 150;

; The number of times to retry locking the session lock, not including the first attempt.
-; Default is 5.
-;memcached.sess_lock_retries = 5;
+; Default is 200.
+;memcached.sess_lock_retries = 200;

Ustawienie w aplikacji ini_set(‚memcached.sess_lock_retries’, 200) rozwiązało problem z lockowaniem się sesji, ale… Wyłącznie w przypadku natywnego rozwiązania, tj. $_SESSION (które bazuje na konfiguracji PHP). Niestety wykorzystanie wspomnianego Phalcon\Session\Adapter\Libmemcached w aplikacji powoduje nadal ten sam błąd. Widać Phalcon (C) nie bierze pod uwagę konfiguracji pecl-memcached (C) i jedzie po swojemu.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: JoShiMa, dodany: 13.01.2019 21:16, tagi: framework, mvc

No i zdarzyło się, że dostałam propozycję, by popracować trochę pisząc aplikacje wykorzystujące zupełnie nowy dla mnie framework web2py. To bardzo ciekawy i zgrabny framework do szybkiego tworzenia aplikacji webowych. Zainicjowany w 2007 roku rozwija się prężnie i ciągle jest aktualizowany, choć jeszcze w oparciu o wersję 2.7 Pythona. W 2011 projekt zdobył nagrodę „Bossie ... Czytaj dalejWeb2py – czyli nowe przyszło szybciej niż się spodziewałam

Autor wpisu: matipl, dodany: 08.01.2019 13:20, tagi: php, oop

Od miesiąca możemy cieszyć się PHP w wersji 7.3, który jest kolejnym krokiem ewolucji jaka zachodzi w tym popularnym języku. Obecne zmiany to dopracowywanie prostszego sposobu tworzenia aplikacji, jak również dopracowywanie samego silnika.

WordPress 5.0 benchmark

Dzięki tym zmianom PHP wciąż przyspiesza. To prawda, że to głównie zasługa coraz lepszego opcache, ale jednak jest to część silnika. WordPress nie jest dobrym przykładem jak powinno się pisać kod, ale jest dobrym przykładem na wzrost wydajności PHP na przestrzeni lat:

  • PHP 5.6: 91.64 req/sec
  • PHP 7.0: 206.71 req/sec
  • PHP 7.1: 210.98 req/sec
  • PHP 7.2: 229.18 req/sec
  • PHP 7.3: 253.20 req/sec

PHP 7.3

PHP 7.3 przyniósł bardzo wiele przydatnych funkcji, które zostały przegłosowane przez społeczność w ramach zgłaszanych RFC. W nowej wersji możemy teraz zostawiać nie tylko przecinek po ostatnim elemencie w tablicy, ale również w wywołaniu metody:

$newArray = array_merge(
    $arrayOne,
    $arrayTwo,
    ['foo', 'bar'],
);

Kolejne wbudowane funkcje zostały wsparte o wyjątki. Tym razem wyjątki zostały wprowadzone do wywołań json_encode() i json_decode(). Oczywiście zgodność wsteczna jest ważna w PHP, dlatego aby został rzucony wyjątek należy dodać parametr JSON_THROW_ON_ERROR:

try {
    $decoded = json_decode("{ 'invalid' : 'json' }", false, 512, JSON_THROW_ON_ERROR);
} catch (\JsonException $e) {
    echo $e->getCode(); // 4
    echo $e->getMessage(); // Syntax error
}

Poza tym pojawiły się…. nowe fukncje. Na przykład is_countable(), która sprawdzi czy rzecz jest policzalna (count() od PHP 7.2 rzuca Warning, gdy jest wykonywane na czymś co jest niepoliczalne). Dodano również monotoniczny timer wysokiej rozdzielczości (hrtime()), który nie ma jeszcze dokumentacji na php.net, ale jest następcą polecenia microtime(), ale jest niezależny od zmiany czasu systemowego.

I na koniec, przypominam, że obecnie wspierane wersje PHP zaczynają się od wersji 7.1. Wersja 7.0 oraz 5.6 nie posiada już żadnego wsparcie, nawet łatek bezpieczeństwa.

PHP 7.4 – Typowanie 2.0

Jednym z większych przełomów jakie przyniósł PHP 7 (2015) jest możliwość deklaracji typów. Tego czego wciąż brakuje, to możliwość ustalenia typu właściwości klasy już na etapie jej opisywania, a nie tworzenia metod. PHP 7.4, który pojawi się pod koniec 2019 roku rozwiąże ten problem.

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

Po wprowadzeniu Typed Properties 2.0, komentarze w PHP znów będą służyły do komentowania kodu, a nie uzupełniały braki języka poprzez @param, @return itp. Pozostaje czekać.

Artykuł PHP 7.3 na pokładzie, przed nami PHP 7.4 pochodzi z serwisu Mateusz matipl Kamiński.

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.