Witam serdecznie. Jeśli chodzi o nowego PHPa to jestem całkowicie zielony, ale ostatnio na PHPersach w Poznaniu był ten temat poruszany i dowiedziałem się z tej prelekcji bardzo dużo ciekawych informacji. Oto i link do tej prelekcji: https://www.youtube.com/watch?v=g3caJBJ_IrQ...gwC&index=3 Polecam obejrzeć!

No i mamy PHP7. Zainstalowalem, skonfigurowalem i odpaliłem stronki. Jest szybciej. Ze strony technicznej, to usunięto wreszcie te archaiczne elementy, które powinny byc juz dawno usunięte. Dokładnych jeszcze testów nie zdązyłem zrobić ale jak podają inni, jest szybsze od PERL, PYTON, RUBY. więcej informacji można znaleźć tutaj: http://it.esky.pl/2015/08/21/7-funkcjonaln...st-rewolucyjny/.

Tak na marginesie, to jaoś nie sprawdziły się proroctwa osob z początku tego wątku

Ja dzisiaj instalowałem na opensuse i jest odwrotnie. Na 5.6.16 - 32 requesty, na v7 - 28. Według zfdebug zużycie ramu na 5.6 ~11MB, v7 14MB. Z opcache 5.6 - 63 requesty 4,1MB, v7 - 58 requestów 4,4MB. Aplikacja realna nie teoretyczna.

Coś masz nie tak. Miałem podobnie instalując paczkę naughty pod debianem, Wywaliłem i skompilowalem ręcznie i jest ok. Zużycie pamięci jest także dużo niższe niż w piątce.

Sprawdź, czy masz włączone OPCACHE, sprawdź czy strony działaja z wykorzystaniem PHP-FPM. to na początek bo coś na pewno masz nie tak. Sam plik php-7.0.0-fpm musisz stworzyć z odpowiednią zawartością. Polecam instalację i konfigurację według tego opisu https://www.howtoforge.com/tutorial/how-to-...hp-7-on-debian/ Nie musisz mieć Debiana i korzystać z ISPconfig aby wykorzystać ten opis i dostosować wszystko do własnej architektury.

Najlepiej też odpal opcache.php i sprawdź jakie funkcje masz uruchomione, a jakie nie i skonfrontuj to z zalecaną konfiguracją twórców PHP7.

Zalecane zmiany przez twórców PHP7:
; Sets how much memory to use
opcache.memory_consumption=128

;Sets how much memory should be used by OPcache for storing internal strings
;(e.g. classnames and the files they are contained in)
opcache.interned_strings_buffer=8

; The maximum number of files OPcache will cache
opcache.max_accelerated_files=4000

;How often (in seconds) to check file timestamps for changes to the shared
;memory storage allocation.
opcache.revalidate_freq=60

;If enabled, a fast shutdown sequence is used for the accelerated code
;The fast shutdown sequence doesn't free each allocated block, but lets
;the Zend Engine Memory Manager do the work.
opcache.fast_shutdown=1

;Enables the OPcache for the CLI version of PHP.
opcache.enable_cli=1

Mam nadzieję, że post ten w jakiś sposób pomoże Ci w namierzeniu problemu dlaczego u ciebie PHP7 nie działa tak jak powinien, bo to że u ciebie jest wolniej niż u innych to nie wina PHP7 niestety, a konfiguracji lub ewentualnie samej jego instalacji.

Serwer jest dobrze skonfigurowany (lighttpd+php-fpm). Jak pisałem z opcache lub bez (suse ma oddzielnie pakiet php-opcache) Obstawiam raczej że wczesne wersje PHP mają jeszcze dużo błędów. Wystarczy spojrzeć ile było poprawionych segfaultów w RC.

To teraz czekamy na PHP w wersji 7.2 aż kod zostanie ogarnięty na tyle, że będzie od ręki działał na tosterze i na wersję 7.6 aż zagości to na większości serwerów choćby hostingowych.

Ja mam jeszcze dziwniejsza sytuację. O ile aplikacje, takie zwykłe działają szybciej czy zużywają mniej ramu o tyle np. serwery socetów już nie i potrafią się nawet zadławić.

Ja korzystam z wersji 7.0.0, nie RC (pod debianem, nie pod susłem ale nie ma to raczej większego znaczenia), więc się nie wypowiem jak sprawa się ma z RC. Spróbuj skompilować to ze źródeł jak pisałem (z wersji 7.0.0) i daj znać, czy masz dalej ten sam problem.

Nigdzie nie pisałem, że siódemka nie zawiera rzadnych błędów, bo pewnie zawiera (który program zresztą nie zawiera ) Jednak w więszości przypadków nie powinno być problemów. Jest różnica między tym, że nie działa dobrze jeden skrypt (np. są problemy z poprawnym działaniem phphmyadmin instalowanymz paczek pod debianem, który już najnowaszą wersją ściągniętą ze strony phpmyadmina działa dobrze), a tym że nie działa dobrze każdy skrypt, w tym Wordpress, który często podawany jest za przykład przyspieszenia działania stron pod kontrolą PHP7 (działa nawet do 70% szybciej niż pod wersją 5.6, a jak piszą niektórzy od wersji 5.0 nawet 700% szybciej).

Inna sprawa, że bym w rzadnym wypadku nie zainstalował PHP7 obecnie na serwerach produkcyjnych, firmowych i wszędzie tam gdzie nie możemy sobie pozolić nawet na najmniejszy przestój, czy to że coś nam nie zatrybi jak powinno i narazi nas, czy firmę na straty. Inaczej jest jeśli chodzi o wlasne serwery prywatne, gdzie często bardziej zależy nam na jak najniższym koszcie serwera w stosunku do jego wydajności i jak największym upakowaniu tam stron, niż na tym, aby jak najbardziej zminimalizować ryzyko tego, że coś nam nie będzie działało jak należy (wtedy najczęściej zmieniamy sktypt na inny lub dostosowujemy, aby zmusić go do działania jeśli jest naszego autorstwa) lub, że ktoś nam się postara o to, aby nam unieruchomić stronę na jakiś czas . Taka uwaga jeszcze na koniec, zrzuty stron dobrze jest robić zawsze zarówno na serwerach firmowych, produkcyjnych, jak i naszych osobistych prywatnych, aby nie zostac z przysłowiową ręką w nocniku jak coś się stanie

Uważam i zaznaczam, że jest to tylko moja indywidualna opinia, że już teraz warto przejść na PHP7 w miarę możliwości, tym bardziej jeśli jestemy programistą w PHP. Uważam, że wcześniej czy później i tak nas to nie ominie, a czym wcześniej zapoznamy się z jego zmianami i zaczniemy to wykorzystywać w naszych aplikacjach, tym lepiej dla nas.

Na początku myślałem, że może to będzie tak jak z Pythonem i przechodzeniem z Pythona 2.x na 3.x. Jednak w świecie PHP to nie ma racji bytu. Python 2.x jest ciągle wspierany, aktualny plan to wsparcie dla niego do 2020 roku. A PHP? No cóż, tutaj każdej wersji daje się 3 lata i potem ucina jej życie.

Choć wydaje mi się, że PHP 5.x będzie na pewno jeszcze dłuuugo żyć. W tej chwili 70-80% internetu to właśnie PHP 5.x. W 7-demce jest sporo maluśkich zmian (wystarczy przerobić temat "Backward incompatible changes"), które zrywają kompatybilność wsteczną z 5.x, także w przypadku komercyjnych projektów (nie open-source, te na pewno będą przepisane, aby przeżyć - Wordpress, Joomla, Drupal, farmeworki - to wszystko będzie przepisane na bank) przepisanie większej apki na 7.0 będzie raczej niemożliwe - jeśli już biznes będzie się miał zgodzić na jakieś przepisanie, to pewnie na późniejsze wersje PHP, bądź na całkowicie inny język. Przy większych aplikacjach jest problem, aby przejść z wersji 5.3 na PHP 5.4 lub 5.5, a co dopiero na 7.

Gieło ma jednak rację, przeskoczenie na 7 to dobry pomysł - w końcu dni wersji 5.5 i 5.6 są wyliczone. Support dla 5.5 kończy się w połowie 2016 (trochę ponad pół roku), a support 5.6 kończy się za trochę ponad półtora roku (18 miesięcy) - i mimo, że wydaje się, że PHP 5.5, czy PHP 5.6 są całkiem świeże, to ich śmierć jest bliska. Za pół roku PHP 5.5 osiąga EndOfLife i znika ze strony php.net - damn, jak ten czas leci, a jeszcze pół roku temu gdy prosiłem jakiegoś admina o zmianę wersji na 5.5, to pisał, że ta wersja jest jeszcze "za mało stabilna" i zgodził się jedynie na 5.4 (sic!).

Starsi koledzy wiedzą, że półtora roku strzeli jak z bicza, a wtedy na php.net będziemy mieć tylko wersje 7, 7.1 i 7.2. Dobre zapoznanie się z 7-mką to mus.

Może wersja 7.x będzie miałe dłuższy life support z racji dość dużego skoku wydajności i odcięcia części starych metod.

Ale 3 lata to i tak dobrze, O ile będą na bieżąco biblioteki aktualizowane to nie widzę problemu.
Niestety w życiu już tak jest że stare trzeba zmieniać na nowe

Wersja 7.0 będzie mieć 3 lata wsparcia, później powstanie 7.1, 7.2, 7.3 itd. Na 8-semkę raczej poczekamy dłuuugie lata. 7.x szybko nie umrze.

https://make.wordpress.org/core/2015/09/10/...press-and-php7/

Btw... Zawsze sobie mozna zrobic zmienna $php7 i sprawdzac czy jest 7ka czy nie... Zamiast przepisywać cały kod
No chyba ze ktos uzywa jakies badziewia, typu mysql_connect() itp.

[PHP] pobierz, plaintext 
$php7 = version_compare(PHP_VERSION, '7.0.0') >= 0;
 
# ....
 
if ($php7)
{
   # jest php 7
}
else
{
   # starsze od php 7
}
[PHP] pobierz, plaintext 

@ksar To już chyba totalna głupota
To tak jakby zrobić dokładnie to samo dla PHP4

Najlepszy kod to taki który działa w przekroju od PHP 5.0 do 7.0 bez żadnych zmian. Oczywiście to marzenie które jest bez sensu, bo świat idzie do przodu i my musimy iść razem z nim.

Wczoraj pokazala się wersja 7.0.1, z której usunięto troche błędów http://php.net/downloads.php

Taką też wczoraj skompilowałem i uruchomiłem Działa wyśmienicie

Czemu totalna glupota?

Dałem poprostu przyklad bo mnie zdziwilo "przepisywanie od nowa"...
A tak póki nie będzie "standardem" php7 mozna przeciez jako zaslepke zamiast przepisywac od nowa, przy okazji by na wiekszej ilosci serwerow dzialal. Co innego gdy ma sie pewnosc ze projekt np. Nie bedzie sprzedany i na 1 wersji.

Mnie razi nawet uzywanie array() zamiast []. Więc <5.4 bym nie używał, nie wygodne i brzydkie.

Bym chetnie uzyl jeszcze null colasce operator zamiast isset, tez by przyszybszylo w wielu miejscach pisanie kodu(i zmniejszylo jego rozmiar...), ale zmieniłem hosting i 5.6 mam to pol roku sie pomecze jeszcze.

Na szczescie ja nie musze uzywac takich zaslepek :-P, bo robie ze dziala od 5.4 w gore.
Zadnych przestarzalych rzeczy nie uzywam

Za dużo stracisz przy tym czasu i pieniędzy. Jeśli masz dużą aplikację która działa np. do 5.3 lub niżej i chcesz zapewnić kompatybilność z php7 to tylko sztucznie przedłużasz czas zgonu który jest nieunikniony. Na początku będzie miało to sens, ale później będzie trzeba dopisać nowe moduły czy zmienić coś pod indywidualne potrzeby klienta, wtedy staniesz pod ścianą.

No ale nawet jeśli ustawisz zmienną na PHP 7.0, to przecież i tak musisz przejrzeć cały kod aby zrobić wszędzie wyjątki dla wersji 5 i 7, to zajmie więcej pracy niż przepisanie kodu tylko na wersję 7.0.

to wystarczyło by pisać kod zgodny z obiema wersjami, jeśli jest to projekt typu wp gdzie ma się milion kopi na rożnych wersjach a jak się wie, ze się robi już pod 7 a o starym zapomina to problemu nie ma. A wp to trzeba by przepisać na nowo, a nie serwować kod z 19 wieku i się bawić w ifowanie, bo to nie ma najmniejszego sensu. Tak samo można by powiedzieć poco SOLID, poco DI skoro można kod napisać w jednym pliku i strukturalnie, który pewnie zadziała, ale potem powodzenia jak ktoś go odziedziczy po Tobie. Wiec to co zaproponowałeś KsaR, jest po prostu głupie.

To tak jakbyś miał zrobić IFa w samochodach Diesla żeby na E95 latały

Trochę o PHP 7.1 (Po Angielsku):
http://phpocean.com/blog/article/8-cool-fe...e-in-php-7-1/43

Och. PHP dorobiło się w końcu "void"? Fajny bajer z łapaniem wielu wyjątków na raz. Pamiętam jaka to była ulga kiedy pojawiła się taka opcja w Javie. Coraz bardziej lubię pisać w PHP

Na to, to chyba każdy czeka(ł), co prawda do własności ale może do zmiennych też dadzą.

https://wiki.php.net/rfc/typed-properties


To też dobre bo mixed* od php 7.1 ale to lepsze wg. mnie
https://wiki.php.net/rfc/union_types

https://wiki.php.net/rfc/precise_float_value

czy ja wiem czy każdy, jak czekał i koniecznie miał być php to wybrał by hacka

Fajnie, że ma być ale poczekajmy do wydania, bo widziałem już takie co głosowanie było i miało być, a do dzisiaj w core nie ma

BYlem ostatnio na konferencji w Anglii gdzie byl koles co siedzial przy robieniu tych typow (mial o nich wlasna sesje na konferencji) i tak, sa juz one raczej zatwierdzone w php7.1

ps: http://2016.phpsouthcoast.co.uk/speakers/anthony-ferrara/

Już jest stabilne 7.1 (od wczoraj)
ChangeLog 7.1.0-stable

Ja poczekam jeszcze kilka miesięcy zanim będzie stabilne

Przecież to już jest stable

mrc nie wierzy świeżym stabilnym wersjom

ja nie wierzę home.pl

Cokolwiek wychodzi jako stable, przez kilka miesięcy ma same bugfixy. Dopiero gdy ludzie rzucają się na nową wersję i wpuszczają ją na produkcję, to wychodzą chocki-klocki. Lepiej poczekać. Aż tyle nowości nie ma, by szaleć.

Krótka analiza changeloga PHP pokazuje że właśnie tak jest, bugi wychodzą na "większym środowisku testowym", czyli na produkcji. Lepiej trochę poczekać. Chyba że ma się dobre pokrycie kodu testami...

Na 7.1 można poczekać, ale 7 to już minimalna wersja, która żyje

zawsze tak jest, że coś najpierw wychodzi a potem jest to poprawiane