jigpuzzled18 ноя 2015 в 15:00

Мой опыт миграции на PHP 7

2 мин

76K

PHP * Веб-разработка *

Комментарии 56

maxru 18 ноя 2015 в 15:19

Расширение mysql больше недоступно

Как и memcached

jigpuzzled 18 ноя 2015 в 15:24

насколько я понимаю внутренности поменялись гораздо сильнее чем сам язык. Как раз поэтому автор XCache написал что пока нет планов на версию для 7-ки.

pherum 18 ноя 2015 в 16:11

что с memcached не так? на homebrew он устанавливается, только доступен из ветки dev-master
видимо выкатят стабильную версию после релиза самого php7

Blumfontein 19 ноя 2015 в 04:38

memcache или memcacheD?

romy4 18 ноя 2015 в 15:36

То есть, код

$array = [1,2,3];
foreach ( $array as $k=>&$v )
{
    $v = get_something_else(); // return 3 4 5
}
var_dump($array);

что в итоге даст?

jigpuzzled 18 ноя 2015 в 15:42

с & совсем другое дело, тут работать также будет. Имеется ввиду такое:

$a = array(1,2,3);
$b = &$a;
foreach($a as $v) {
    echo "$v\n";
    unset($a[1]);
}

romy4 18 ноя 2015 в 15:53

Понятно, спасибо. Делать unset() внутри foreach никогда не было безопасно.

Sild 19 ноя 2015 в 14:36

Расскажите тогда, как стоит поступать в таких ситуациях?

$a = array("test"=>"1", "test2"=>2, "test3"=>3);
$needed = array("test", "test2");
foreach($a as $i => $v) {
    if(!in_array($i, $needed)) {
        unset($a[$i]);
    }   
}

Ну надо мне провалидировать что-то. Собирать новый массив?

Fesor 19 ноя 2015 в 14:59

Собирать новый массив?

Именно так.

$a = array("test"=>"1", "test2"=>2, "test3"=>3);
$needed = array("test", "test2");

$a = array_filter($a, function ($item) {
     return in_array($item, $needed);
});

bolk 20 ноя 2015 в 14:09

Вы use($needed) забыли.

romy4 20 ноя 2015 в 12:16

Нашёл два замечательных поста: [1] Тонкости работы foreach в php [2] References in foreach

Sild 20 ноя 2015 в 15:28

Наткнулся в комментариях на ещё один пост: http://habrahabr.ru/post/114899/

У меня прям все написанные исходники перед глазами пронеслись. Думал в такие моменты, что нужно больше спать, и переписывал на if-else.

romy4 21 ноя 2015 в 10:53

Да, TheShock умеет «накинуть» :) Там же в комментах, вместо if-else

switch(true){
    case isCondFirst():
        value = valueFirst();
        break;
    case isCondSecond():
        value = valueSecond();
        break;
    case isCondThird():
        value = valueThird();
        break;
    default:
        value = valueDefault();
}

просто нечто.

nowm 23 ноя 2015 в 04:11

Я конкретно эту ситуацию имею ввиду:

$a = ['test' => '1', 'test2' => 2, 'test3' => 3];
$filter = ['test', 'test2'];

$a = array_intersect_key($a, array_flip($filter));

Если ситуация отличается, то и решение может быть другое. Но вот в данном конкретном случае такой код лучше подойдёт, мне кажется. Как минимум, одной переменной меньше и используются встроенные функции, вместо реализации алгоритма вручную.

dim_s 19 ноя 2015 в 07:23

А что если?

$a = array(1,2,3);
foreach($a as $i => $v) {
    echo "$v\n";
    $a[$i] = $v * 2;
}

var_dump($a); // ???

jigpuzzled 19 ноя 2015 в 09:23

3v4l.org/ru9Zv

romy4 19 ноя 2015 в 12:39

какая полезная песочница. Я постоянно юзал sandbox.onlinephpfunctions.com

romy4 18 ноя 2015 в 15:39

И мне нужен xdebug для отладки, а то без него ой как плохо отлаживать сложные прыжки в коде. Жду, когда они 2.4.0 в релиз выпустят.

jigpuzzled 18 ноя 2015 в 15:45

Ну на сервере то отладка не пригодиться. Так что это не такая-уж проблема, хотя конечно неприятно разрабатывать на одном а деплоить на другой. Этот пост скорее мотиватор пофиксить у себя все E_STRICT чтобы потом боком не вылезли.

romy4 18 ноя 2015 в 15:53

Я для себя придерживаюсь железного правила:

ini_set("error_reporting",65535);

и чтобы не было ни одного уведомления в работе. Жаль только, такого очень трудно достичь используя чужие фреймворки.

jigpuzzled 18 ноя 2015 в 16:02

В PHPixie все строго, заходи =)

НЛО прилетело и опубликовало эту надпись здесь

romy4 18 ноя 2015 в 16:44

Я имел в виду E_ALL и ещё один бит.

bolk 19 ноя 2015 в 06:19

error_reporting(-1);

НЛО прилетело и опубликовало эту надпись здесь

seregagl 4 дек 2015 в 06:57

Версии должны быть одинаковыми, но расширению xdebug на продакшене не место, оно жутко тормозное

Fesor 19 ноя 2015 в 10:51

Есть phpdbg

stalkerg 18 ноя 2015 в 18:57

А адаптеры для Postgres шевелятся?

jigpuzzled 18 ноя 2015 в 20:57

так они в PDO входят же, так что конечно

Fesor 19 ноя 2015 в 10:48

ext-pgsql работает без нареканий.

summerwind 18 ноя 2015 в 20:38

Для примера простой сайт на PHPixie заработал почти в три раза быстрее практически сравнившись со скоростью Phalcon на PHP 5.6, несколько сайтов на Wordpress показали стабильный прирост в скорости в два раза.

Странные какие-то сравнения. В два, в три раза… По сравнению с чем? Какие задачи сравнивались? Какие операции?
Если учесть, что в обычных сайтах основная часть времени уходит на запросы к БД, то непонятно, как смена версии PHP могла это ускорить. Или там на сайтах интегралы численными методами высчитываются?)

jigpuzzled 18 ноя 2015 в 20:57

основная часть времени уходит на запросы к БД

это давно уже совсем не так, вот например бенчмарки от Techempower: www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=fortune&l=sg

По условиям теста запросов у каждого фреймворка получается столько же, но вот скорость сильно отличается

SamDark 19 ноя 2015 в 10:24

Сегфолтит семёрка пока по-страшному. Правят оперативно, но надо больше тестов. Прошу всех погонять свои проекты и заслать в багтрекер трейсы, дампы или, что вообще лучше всего, короткие кусочки кода, которые PHP валят.

zou 19 ноя 2015 в 10:32

Сейчас пишу новый проект на семерке. Стремно, но пишу. Пока что не словил ни единого бага, вылета и тд. Расширения спокойно собрал вручную, все что для проекта нужно — работает. Вот интересно что может быть аргументом против запуска нового проекта на РНР 7 на следующий день после его релиза.

SamDark 19 ноя 2015 в 11:08

Против проверки на тестовом сервере — ничего. Против выката на продакшн много чего. Как минимум стоит спланировать откат до 5.6 в деталях.

Fesor 19 ноя 2015 в 11:23

У меня коллеги как раз таки из-за сегфолтов php5.6 апнулись на семерку. hhvm как оказалось отвратительно работает с postgresql.

Это я к чему, для любого апдейта должны быть причины. Уж темболее если это апдейта на релиз кандидат или бетку.

SamDark 19 ноя 2015 в 12:06

Думаю, получить от 30% прироста производительности — хороший аргумент за переход на семёрку. Но делать это надо осторожно.

sergebezborodov 19 ноя 2015 в 15:30

Саш, а как с yii на семерке?

SamDark 19 ноя 2015 в 15:48

В общем и целом отлично. Код работать будет. Все сегфолты воспроизведены и закинуты в трекер. Большинство Расмус уже поправил.

Новых фич семёрки, конечно же, из за обратной совместимости, не используем пока.

sergebezborodov 19 ноя 2015 в 16:13

интересно очень, дождусь релиза и запущу отдельный сервер с семеркой и налью часть трафа hotwork.ru померяю реальное ускорение

Fesor 19 ноя 2015 в 16:23

неужели у вас нет старых добрых нагрузочных тестов?

sergebezborodov 19 ноя 2015 в 16:32

не применяли, в системе 100к суточных визитов, нагрузка растет плавно, поэтому гонять нагрузку в суточные 1млн визитов смысла особо нет
а ливануть пару тыс живого трафа на хорошее дело всегда можно ;)

WellWisher 19 ноя 2015 в 10:58

Если только отсутствие нужных библиотек, совместимых с PHP 7.
Пока дойдете до релиза думаю что если «вдруг» что-то и появится внезапное, — то всё будет пофикшено.

Fesor 19 ноя 2015 в 11:02

на данный момент есть аж 2 инструмента что бы помочь быстрее мигрировать проекты на php7:

— github.com/Alexia/php7mar
— github.com/sstalle/php7cc

В принципе популярные фреймворки уже совместимы с PHP7. В частности у Symfony небыло никаких проблем.

bolk 20 ноя 2015 в 14:10

Безумству храбрых поём мы песню, конечно. На ветке PHP7 постоянно находятся неприятные баги. Падения, зацикливания, утечки. Например описание сегодняшнего исправления такое: «try{ } finally{} can create infinite chains of exceptions».

Acuna 8 дек 2015 в 15:47

А Вы злостный хейтер?) Тогда не портите радость другим, ее в мире не так много. Ну переходят и переходят, они же не конкуренты Вам.

bolk 8 дек 2015 в 15:52

Хейтер чего? Перехода на PHP7 что ли? Нет, собираюсь. Версий через 10.

Acuna 10 дек 2015 в 15:56

Ну согласитесь, что Вы написали это не для простого информирования, ибо мы с Вами оба знаем, что переходящие на него далеко не блондинки или школота, и основательно начитаны о плюсах и минусах такого перехода, ибо это Вам не с 5.4 на 5.5 перейти. Да и тут все относительно, не помню с какой версии и на какую я переходил, но когда оператор e в регулярках оказался деперекейтед и вместо этого теперь нужно пользовать preg_replace_callback, вот это был переход через альпы!))) Почти весь проект переписали… До сих пор помню…

Fesor 8 дек 2015 в 18:26

try{ } finally{} can create infinite chains of exceptions

этот баг воспроизводится в PHP 5.6.15, так что никакого отношения к семерке.

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

bolk 8 дек 2015 в 18:28

Ну так это один пример только. Для интереса гляньте сколько уже всего исправлено в 7.0.1, и это только начало!

Fesor 8 дек 2015 в 18:49

Волков бояться в лес не ходить. Не бывает проектов без багов. В том функционале который использует 99% php разработчиков баги уже вычистили, остаются фичи или варианты использования фич которые просто редко юзаются.

В целом проблемы о которых вы толкуете выявляет толковая тест сюита проекта. Если у вас нет оной — то мне понятно ваше нежелание мигрировать на новую ветки php. Но это ваша проблема а не проблема php.

сколько уже всего исправлено в 7.0.1

7.0.1 еще нет, даже тег не выставлен. Если вы про ветку то это как бы… просто ветка. А динамика коммитов как бы не менялась, а закрывающиеся баги это замечательно.

bolk 8 дек 2015 в 18:56

> В целом проблемы о которых вы толкуете выявляет толковая тест сюита проекта. Если у вас нет оной — то мне понятно ваше нежелание мигрировать на новую ветки php. Но это ваша проблема а не проблема php
Мне что-то даже и сказать нечего. У вас однопользовательская однопроцессорная система на одном процессе, покрытая на 100% тестами?
> 7.0.1 еще нет, даже тег не выставлен.
И что? Я не говорю, что версия вышла, я говорю о том сколько багов сейчас в 7.0 видно по тому что правится 7.0.1.

Fesor 8 дек 2015 в 19:14

У вас однопользовательская однопроцессорная система на одном процессе, покрытая на 100% тестами?

нет. Модель работы php (умирающая) позволяет не париться о кейсах с кучей людей одновременно ломящихся на сайт (если мы говорим о рисках связанных конкретно с миграцией версии PHP, а не разработки в целом). А 100% покрытие кода тестами не нужно, хватит и 80%. Да и без мутационных тестов ваши эти проценты покрытия как бы не сильно показательны.

Ну и я вам даже больше скажу, у меня рядом ребятки сидят, они пару недель назад переехали на php7 потому что 5.6 на их проектах после каждого запроса сегфолтился при отчистке памяти.

я говорю о том сколько багов сейчас в 7.0 видно по тому что правится 7.0.1.

если вы проследуете в ишус трекер — то большая часть багов идет еще с php 5.6. А количество коммитов на единицу времени чуть подупало после релиза, и в принципе все держится относительно стабильно. Обычный рабочий процесс.

Короче я не вижу ровным счетом никаких проблем с миграцией проектов на семерку, если в этом есть профит. А профит для большинства проектов таки есть.

bolk 8 дек 2015 в 19:21

нет. Модель работы php (умирающая) позволяет не париться о кейсах с кучей людей одновременно ломящихся на сайт

Тем не менее при переезде с 5.5 на 5.6 мы словили пару гонок за ресурсы в файлах.

А 100% покрытие кода тестами не нужно, хватит и 80%.

Или не хватит.

если вы проследуете в ишус трекер — то большая часть багов идет еще с php 5.6

Ок, я потом посмотрю. Тут дело не в количестве, а в серьёзности.

Ну и я вам даже больше скажу, у меня рядом ребятки сидят, они пару недель назад переехали на php7 потому что 5.6 на их проектах после каждого запроса сегфолтился при отчистке памяти.

Увы, да. Там настройки opcache надо покрутить.

Короче я не вижу ровным счетом никаких проблем с миграцией проектов на семерку, если в этом есть профит. А профит для большинства проектов таки есть.

Ну, для сайтиков — почему бы и нет?

Fesor 8 дек 2015 в 20:14

мы словили пару гонок за ресурсы в файлах.

Какая-то уж больно экзотическая проблема. Могли бы вы рассказать? Мне на самом деле интересно.

Или не хватит.

Ну конечно все зависит от требований к проекту, его сроке жизни и т.д. Я лишь хочу сказать что честные 100% покрытие кода тестами невозможно достич как минимум потому что вам нужно будет покрыть все инварианты. И даже если код комередж показывает 100% только мутационные тесты (а под php этот вид тестирования не очень развит, хотя даже инструменты имеются) могут показать истенное положение дел.

Увы, да. Там настройки opcache надо покрутить.

Нет, к opcache это не имело никакого отношения. Это было в списке первых 10-ти вариантов того, что можно сделать. Собственно там очень специфичная бага связанная с конкретными экстеншенами сторонними, и комбинация нескольких факторов приводила к сегфолтам.

Ну, для сайтиков — почему бы и нет?

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

Я к тому что не надо агитировать людей что-то делать или чего-то не делать. Пусть сами принимают решения и взвешивают риски.

bolk 9 дек 2015 в 04:28

Я думаю, пора наш диалог сворачивать. Мы с вами, похоже, из разных миров.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий